1
00:00:00,160 --> 00:00:02,320
That was weird. 
Like I didn't expect NFTS to 

2
00:00:02,320 --> 00:00:04,160
take off. 
I didn't expect meme coins to 

3
00:00:04,160 --> 00:00:07,240
take off. 
I think the big innovation in 

4
00:00:07,240 --> 00:00:10,720
blockchain is actually that you 
can create programmatic market 

5
00:00:10,720 --> 00:00:14,200
makers through Amms and all 
these kind of clever curves that

6
00:00:14,280 --> 00:00:18,760
eliminate a lot of the layers 
that you have in Trad 5 that are

7
00:00:18,760 --> 00:00:22,160
necessary to get to run Trad 5 
based trading. 

8
00:00:22,400 --> 00:00:26,440
My feeling with MEV was that we 
need to maximize competition so 

9
00:00:26,440 --> 00:00:30,640
users always have the option to 
go to the best source force for 

10
00:00:30,640 --> 00:00:32,759
their trade. 
Whether that means that 

11
00:00:32,840 --> 00:00:36,360
validator is maximum sandwiching
and I'm giving everybody a 

12
00:00:36,360 --> 00:00:39,120
rebate, that could be one model 
that actually works. 

13
00:00:39,360 --> 00:00:42,360
If there's truly an exploit and 
you continue running the chain, 

14
00:00:42,360 --> 00:00:45,560
even if you allow like define 
liquidations to run, they're 

15
00:00:45,560 --> 00:00:48,760
mixed in with exploited 
transactions as as Ethereum 

16
00:00:48,760 --> 00:00:50,880
folks, I don't know if you're 
around for the Dow hack. 

17
00:00:50,920 --> 00:00:54,680
The only reason they were able 
to deal with the hard fork is 

18
00:00:54,680 --> 00:00:56,960
because it was locked. 
All that, all those funds were 

19
00:00:56,960 --> 00:00:59,080
locked up in the smart contract 
that connects it. 

20
00:00:59,080 --> 00:01:01,960
If they started getting mixed 
with a whole bunch of things 

21
00:01:01,960 --> 00:01:03,960
like it's just impossible to 
unravel. 

22
00:01:03,960 --> 00:01:05,519
You can't roll back the real 
world. 

23
00:01:05,560 --> 00:01:08,360
There's action that's taking in 
the real world based on the 

24
00:01:08,360 --> 00:01:11,880
chain state Circle is sending 
funds out based on like mint and

25
00:01:11,880 --> 00:01:14,760
burns, right? 
I think once you have 4 clients,

26
00:01:14,760 --> 00:01:18,600
you could say that the 
probability of a bug in three is

27
00:01:18,640 --> 00:01:21,960
so much smaller than the 
probability in bug in two that 

28
00:01:21,960 --> 00:01:24,600
it's fine for one to be down. 
And then you can do this kind of

29
00:01:24,600 --> 00:01:27,200
maintain some lightness while 
while one is down and and 

30
00:01:27,200 --> 00:01:29,360
rotate. 
Welcome to Epicenter, the show 

31
00:01:29,360 --> 00:01:31,360
which talks about the 
technologies, projects and 

32
00:01:31,360 --> 00:01:33,880
people driving decentralization 
and the blockchain revolution. 

33
00:01:33,880 --> 00:01:38,600
I'm Brian Crane and today I'm 
joined with my guest host, 

34
00:01:38,720 --> 00:01:42,480
Martin Krapplemann, who is the 
founder of Gnosis. 

35
00:01:43,040 --> 00:01:47,600
And we have a very special 
returning guest today, Anatoly, 

36
00:01:48,040 --> 00:01:51,800
the Co founder of Solana. 
Of course, Solana needs needs no

37
00:01:51,800 --> 00:01:54,040
introduction. 
So we're excited today to talk, 

38
00:01:55,000 --> 00:01:57,600
you know, get into the wheeze a 
little bit of where Solana is 

39
00:01:57,600 --> 00:02:00,360
at, what's coming for Solana, 
some of the challenges. 

40
00:02:01,000 --> 00:02:04,360
So really excited for that. 
And now, just before we go into 

41
00:02:04,360 --> 00:02:07,600
it with Anatoly, I want to share
a few words from our sponsors 

42
00:02:07,600 --> 00:02:10,720
this week. 
If you're looking to stake your 

43
00:02:10,720 --> 00:02:13,800
crypto with confidence, look no 
further than Course one. 

44
00:02:14,240 --> 00:02:17,840
More than 150,000 delegators, 
including institutions like Bit 

45
00:02:17,840 --> 00:02:19,480
Gold, Pantera Capital and 
Ledger. 

46
00:02:19,480 --> 00:02:21,000
Trust. 
Course one with the assets. 

47
00:02:21,440 --> 00:02:23,800
They support over 50 block 
chains and are leaders in 

48
00:02:23,800 --> 00:02:27,000
governance or networks like 
Cosmos, ensuring your stake is 

49
00:02:27,000 --> 00:02:29,960
responsibly managed. 
Thanks to the advanced MEV 

50
00:02:30,040 --> 00:02:32,800
research, you can also enjoy the
highest staking rewards. 

51
00:02:33,240 --> 00:02:36,280
You can stake directly from your
preferred wallet, set up a white

52
00:02:36,280 --> 00:02:40,040
label note, restake your assets 
on Eigenia or Symbiotic, or use 

53
00:02:40,040 --> 00:02:42,320
the SDK for multi chain staking 
in your app. 

54
00:02:42,840 --> 00:02:45,960
Learn more at Chorus .1 and 
start staking today. 

55
00:02:47,640 --> 00:02:50,840
This episode is proudly brought 
to you by Gnosis, a collective 

56
00:02:50,840 --> 00:02:53,320
dedicated to advancing a 
decentralized future. 

57
00:02:53,840 --> 00:02:58,000
Gnosis leads innovation with 
Circles, Gnosis Pay and Metri 

58
00:02:58,120 --> 00:03:00,320
reshaping open banking and 
money. 

59
00:03:00,640 --> 00:03:03,720
With Hashi and Gnosis VPN, 
they're building a more 

60
00:03:03,720 --> 00:03:06,240
resilient, privacy focused 
Internet. 

61
00:03:06,680 --> 00:03:10,080
If you're looking for an L1 to 
launch your project, Gnosis 

62
00:03:10,080 --> 00:03:12,720
Chain offers the same 
development environment as 

63
00:03:12,720 --> 00:03:15,240
Ethereum with lower transaction 
fees. 

64
00:03:15,520 --> 00:03:19,520
It's supported by over 200,000 
ballot errors, making Gnosis 

65
00:03:19,520 --> 00:03:22,440
Chain a reliable and credibly 
neutral foundation for your 

66
00:03:22,440 --> 00:03:25,720
applications. 
Gnosis Dow drives Gnosis 

67
00:03:25,720 --> 00:03:28,120
governance, where every voice 
matters. 

68
00:03:28,480 --> 00:03:31,760
Join the Gnosis community in the
Gnosis Dow forum today. 

69
00:03:32,440 --> 00:03:36,400
Deploy on the EVM compatible 
Gnosis Chain or secure the 

70
00:03:36,400 --> 00:03:40,760
network with just one GNO and 
affordable hardware. 

71
00:03:41,160 --> 00:03:44,880
Start your decentralization 
journey today at gnosis dot IO. 

72
00:03:46,240 --> 00:03:47,920
Cool. 
Well, thanks so much for coming 

73
00:03:47,920 --> 00:03:50,680
on and totally, it's really 
great to have you back. 

74
00:03:52,160 --> 00:03:56,360
Yeah, thanks for having me. 
So I wanted to start off with, 

75
00:03:56,760 --> 00:04:00,880
so the original Solana vision 
right from, you know, now it's 

76
00:04:00,880 --> 00:04:07,000
like 7 years ago or so was to 
have blockchain at NASDAQ speed.

77
00:04:07,560 --> 00:04:11,320
And you know, at the time, 
Solana was really pretty alone 

78
00:04:11,760 --> 00:04:16,279
in trying to do a blockchain, 
you know, a single chain, high 

79
00:04:16,279 --> 00:04:21,839
throughput, maximum performance 
speed, the time sharding was 

80
00:04:21,839 --> 00:04:25,480
like the hot thing when it came 
to how to scale blockchains and,

81
00:04:25,480 --> 00:04:28,800
and you guys were kind of alone.
Of course, today, you know, 

82
00:04:28,800 --> 00:04:31,520
Solana has gotten lots of 
traction and also the idea of 

83
00:04:31,520 --> 00:04:34,720
single throughput chain has is 
something that's gotten a lot 

84
00:04:34,720 --> 00:04:37,120
more traction with a lot of 
other companies pursuing 

85
00:04:37,120 --> 00:04:40,520
something similar. 
But just just sort of zooming 

86
00:04:40,520 --> 00:04:45,000
out, like when you think back to
your vision at the beginning and

87
00:04:45,080 --> 00:04:48,120
where it's at right now, how do 
you feel about it? 

88
00:04:48,120 --> 00:04:51,360
What do you think is are some 
things that you know happened 

89
00:04:51,360 --> 00:04:53,880
like you planned? 
What are some things that maybe 

90
00:04:53,880 --> 00:04:56,720
haven't worked out? 
Yeah. 

91
00:04:56,720 --> 00:05:01,120
I mean a lot of stuff kind of 
came true that I thought would, 

92
00:05:01,120 --> 00:05:05,920
but just in different order. 
Like the, the order was 

93
00:05:05,920 --> 00:05:10,200
unpredictable and the 
applications are also were 

94
00:05:10,200 --> 00:05:13,760
unpredictable. 
You know, we, we thought that 

95
00:05:13,760 --> 00:05:17,600
trading was going to be a really
important use case, but we 

96
00:05:17,600 --> 00:05:19,920
didn't think it was going to be 
the most important use case. 

97
00:05:19,920 --> 00:05:23,960
I think to me that's pretty 
obvious that like execution of 

98
00:05:23,960 --> 00:05:27,760
and launching assets and 
execution of the trades between 

99
00:05:27,760 --> 00:05:32,920
them is what's driving most of 
the volumes and revenues for 

100
00:05:33,240 --> 00:05:36,600
across all the applications and 
block and, and layer ones and 

101
00:05:36,600 --> 00:05:38,640
layer twos. 
This is where all the fees come 

102
00:05:38,640 --> 00:05:40,600
from. 
And if you don't have revenues, 

103
00:05:40,600 --> 00:05:43,480
you can't, no matter how many 
tokens you launch, you can't 

104
00:05:43,480 --> 00:05:45,640
afford to pay all the all six 
engineers. 

105
00:05:47,160 --> 00:05:49,880
Somebody somewhere has to figure
out how to, how to make 

106
00:05:49,880 --> 00:05:55,280
revenues. 
And I, I think that came true. 

107
00:05:55,600 --> 00:06:01,240
But what surprised me was that 
how slow Trat 5 was adopting 

108
00:06:01,240 --> 00:06:04,280
this stuff. 
I expected like stocks and all 

109
00:06:04,280 --> 00:06:06,240
of these things to be the main 
usage. 

110
00:06:06,480 --> 00:06:08,800
But right now it's basically 
like gaming. 

111
00:06:08,800 --> 00:06:13,720
Like it's an NFTS and meme coins
are like, if you look at Twitch 

112
00:06:13,720 --> 00:06:18,000
streamers that are streaming 
trading it, it's exactly the 

113
00:06:18,000 --> 00:06:20,840
same content as when they're 
streaming mobile gaming or any 

114
00:06:20,840 --> 00:06:23,480
kind of game. 
It is effectively gaming. 

115
00:06:23,960 --> 00:06:25,960
It's just kind of PvP loot 
boxes. 

116
00:06:26,160 --> 00:06:27,840
This is what I kind of how I 
think of it. 

117
00:06:29,640 --> 00:06:31,840
That was weird. 
Like I didn't expect NF TS to 

118
00:06:31,840 --> 00:06:33,720
take off. 
I didn't expect meme coins to 

119
00:06:33,720 --> 00:06:36,440
take off, but they're using the 
same technology. 

120
00:06:36,440 --> 00:06:41,480
It's the same kind of escrow 
auction processes on chain. 

121
00:06:42,080 --> 00:06:45,520
I thought like central limit 
order books would be the killer 

122
00:06:46,280 --> 00:06:51,360
way to run markets on chain. 
But I think the big innovation 

123
00:06:51,360 --> 00:06:55,440
in blockchain is actually that 
you can create programmatic 

124
00:06:55,440 --> 00:06:58,800
market makers through Amms and 
all these kind of clever curves 

125
00:06:59,440 --> 00:07:03,800
that eliminate a lot of the 
layers that you have in 

126
00:07:03,800 --> 00:07:08,920
Stradfight that are necessary to
get to run like tradfight based 

127
00:07:08,920 --> 00:07:11,840
trading. 
And that's pretty interesting. 

128
00:07:11,840 --> 00:07:15,800
And even if the Amms are less 
efficient, the cost that you 

129
00:07:15,800 --> 00:07:19,920
spent on professional market 
makers like citadels and jumps 

130
00:07:20,320 --> 00:07:23,400
are still large that you might 
actually as a early stage 

131
00:07:23,400 --> 00:07:28,280
company, you might be better off
using an AM to be honest versus 

132
00:07:28,280 --> 00:07:32,160
like the the more professional 
Triadfi approach. 

133
00:07:33,360 --> 00:07:35,600
That was unexpected. 
And I think that's a legitimate 

134
00:07:35,600 --> 00:07:38,720
innovation. 
I think where you see the 

135
00:07:38,720 --> 00:07:43,240
explosion of assets and how 
they're traded, it's primarily 

136
00:07:43,240 --> 00:07:47,440
through automatic based kind of 
market making approaches like 

137
00:07:47,440 --> 00:07:51,160
curves and bonding curves and AM
Ms. and stuff like that. 

138
00:07:53,440 --> 00:07:59,320
I I would like to jump in on a 
topic you you hinted at and I 

139
00:07:59,320 --> 00:08:02,600
think it's people have very 
different opinions about it. 

140
00:08:02,920 --> 00:08:10,320
What makes blockchain valuable? 
Where does or you, you mentioned

141
00:08:10,320 --> 00:08:13,040
fees and said, yeah, somewhere 
there needs to be fees. 

142
00:08:13,320 --> 00:08:17,240
And I think at least in Ethereum
land, there is kind of this, 

143
00:08:17,240 --> 00:08:22,880
this, this debate between should
either be just money and somehow

144
00:08:22,880 --> 00:08:25,880
that's where the value comes 
from or should should there be 

145
00:08:26,040 --> 00:08:28,680
transaction fees? 
Seems like you have a very clear

146
00:08:29,000 --> 00:08:33,320
clear answer here. 
I'm traditional conservator. 

147
00:08:34,000 --> 00:08:37,320
You have, you know, discounted 
future cash flows that would 

148
00:08:37,320 --> 00:08:41,080
give stuff value. 
There's exceptions to that, but 

149
00:08:41,080 --> 00:08:44,200
I think they're the outliers. 
You can't engineer for them. 

150
00:08:44,560 --> 00:08:47,120
This is the problem that I have 
with like, oh, Bitcoin is so 

151
00:08:47,120 --> 00:08:51,520
successful, therefore we must 
build a better a better Bitcoin.

152
00:08:53,040 --> 00:08:55,840
I don't understand the 
engineering reasons why Bitcoin 

153
00:08:55,840 --> 00:08:58,240
is successful. 
So therefore I cannot build a 

154
00:08:58,240 --> 00:09:01,640
better Bitcoin. 
So would it be fair to say the 

155
00:09:02,000 --> 00:09:05,760
number one or you could have one
absolutely crucial success 

156
00:09:05,760 --> 00:09:08,280
metric for Solana is overall 
fees. 

157
00:09:09,840 --> 00:09:13,160
Yeah, I think the the network 
needs 7 of fees to pay for all 

158
00:09:13,160 --> 00:09:16,480
the engineering effort and the 
validators and all this stuff. 

159
00:09:16,720 --> 00:09:21,920
If it doesn't have that, I think
they will eventually die that 

160
00:09:21,920 --> 00:09:26,040
that's kind of my belief. 
So where do you think fees will?

161
00:09:26,240 --> 00:09:30,840
What will be the scarce thing 
that people will pay fees for? 

162
00:09:30,840 --> 00:09:35,680
So I mean, generally speaking 
there is, is it just general 

163
00:09:35,680 --> 00:09:40,080
block space or you would say 
block space in general will be 

164
00:09:40,320 --> 00:09:43,280
more or less free and it's 
specifically congestion block 

165
00:09:43,280 --> 00:09:45,240
space or congested block space 
or? 

166
00:09:45,240 --> 00:09:49,160
Yeah, I think what the value 
that these systems provide is 

167
00:09:51,040 --> 00:09:55,760
the F state that has an economic
opportunity with cost and the 

168
00:09:55,760 --> 00:09:57,760
pre organization to access that 
state. 

169
00:09:58,680 --> 00:10:03,000
And this is where you can charge
more than the, the hardware and 

170
00:10:03,000 --> 00:10:05,400
the bandwidth and all the, the 
nuts and bolts. 

171
00:10:05,960 --> 00:10:10,120
And if you're purely, purely 
selling hardware, you know, 1000

172
00:10:10,120 --> 00:10:14,920
replicated amount of storage or 
whatever, you can only charge so

173
00:10:14,920 --> 00:10:18,400
many more multiples off the cost
of the hardware, like maybe 10X.

174
00:10:18,720 --> 00:10:24,520
Otherwise a competitor will just
underbid you and you will lose 

175
00:10:24,520 --> 00:10:27,240
this way because hardware just 
constantly keeps getting cheaper

176
00:10:27,240 --> 00:10:29,040
and cheaper. 
And your dominant costs are 

177
00:10:29,040 --> 00:10:31,480
always going to be the people, 
right? 

178
00:10:31,480 --> 00:10:34,320
Like it's just the at the end of
the day, it's the you got to pay

179
00:10:34,320 --> 00:10:36,720
for the, all the, all the 
engineering stuff. 

180
00:10:37,920 --> 00:10:44,960
So this is where I think like 
probably again, why Solan is so 

181
00:10:44,960 --> 00:10:49,240
has such a different road map 
than Ethereum is that I, I think

182
00:10:49,240 --> 00:10:52,160
that the network cannot survive 
without the execution layer also

183
00:10:52,160 --> 00:10:57,920
paying for, for the all the cost
to build the data availability 

184
00:10:57,920 --> 00:11:00,480
and all this other stuff. 
The execution layers where you 

185
00:11:00,480 --> 00:11:05,160
can charge real real fees based 
on content and everything else 

186
00:11:05,160 --> 00:11:10,080
has to support that. 
So the, I mean what you just 

187
00:11:10,080 --> 00:11:14,800
said kind of priority access to,
to yeah, economically important 

188
00:11:15,800 --> 00:11:20,880
content kind of mev, right. 
Yeah, yeah, absolutely. 

189
00:11:22,160 --> 00:11:32,480
SO11 theory people have been 
discussing is that MEV was or 

190
00:11:32,480 --> 00:11:35,800
definitely in Ethereum for a 
while it was very much captured 

191
00:11:35,800 --> 00:11:39,920
by the chain and and by 
validators. 

192
00:11:40,400 --> 00:11:46,320
But to some extent now it seems 
to be moving more towards the 

193
00:11:46,640 --> 00:11:51,480
applications or in principle 
applications have the power to 

194
00:11:52,480 --> 00:11:58,080
yeah to kind of add extra rules 
on top and and kind of protect 

195
00:11:58,080 --> 00:12:03,160
their MEV. 
Do you see that as a as a danger

196
00:12:03,160 --> 00:12:05,320
for Solana in that case? 
No, no. 

197
00:12:05,320 --> 00:12:11,760
I think it's the goal for Solana
is to so there's designs for 

198
00:12:11,760 --> 00:12:15,320
application sequencing. 
I actually proposed 1A while 

199
00:12:15,320 --> 00:12:18,560
back called program writable 
accounts. 

200
00:12:18,560 --> 00:12:21,360
I don't know Brian, if you were 
involved as shooting down that's

201
00:12:21,360 --> 00:12:25,320
empty. 
But basically the idea is that I

202
00:12:25,320 --> 00:12:29,880
felt that it's important to for 
apps to be able to set the cost 

203
00:12:29,880 --> 00:12:32,120
to, to take a right lock on 
their state. 

204
00:12:32,520 --> 00:12:35,480
So that economically important 
state that's important to 

205
00:12:35,480 --> 00:12:39,040
access. 
If the application can say, hey,

206
00:12:39,040 --> 00:12:42,120
to be able to write to the state
cause access really means right 

207
00:12:42,120 --> 00:12:46,240
to modify it to take that offer.
I want to set the fee and have 

208
00:12:46,240 --> 00:12:49,960
that fee be application specific
and dynamic and controlled by 

209
00:12:49,960 --> 00:12:53,840
the business logic of the app 
that would eat into some of the 

210
00:12:53,880 --> 00:12:58,240
fees that the chain captures. 
But what's good for the goose is

211
00:12:58,240 --> 00:13:01,360
good for the gander. 
Basically that system would 

212
00:13:01,360 --> 00:13:05,280
preserve atomic composition 
between applications and the 

213
00:13:05,520 --> 00:13:09,160
cross atomic all the arbitrage 
between all the apps that are 

214
00:13:09,160 --> 00:13:13,320
extremely profitable that you 
cannot remove, right. 

215
00:13:13,320 --> 00:13:16,840
If if each application then 
moves off chain and runs their 

216
00:13:16,840 --> 00:13:20,680
own L1 or L2 or whatever their 
own separate environment per 

217
00:13:20,680 --> 00:13:25,240
app, then you lose that atomic 
composition and you effectively 

218
00:13:25,240 --> 00:13:30,720
lose those revenues. 
So what I want to see is the L1 

219
00:13:30,720 --> 00:13:34,600
Solana, this giant, one giant 
atomic state machine, its 

220
00:13:34,600 --> 00:13:38,600
revenue to be mostly driven by 
this, the, the opportunities 

221
00:13:38,600 --> 00:13:41,120
that arise from having 
everything in one, one's giant 

222
00:13:41,120 --> 00:13:43,640
state machine that's 
synchronous, that's fast, that 

223
00:13:43,640 --> 00:13:46,680
that's as cheap as possible. 
And then give the application 

224
00:13:46,680 --> 00:13:49,040
the tools to capture whatever, 
whatever fees they want. 

225
00:13:49,360 --> 00:13:52,720
And they can tune them, set them
higher, lower, distributed them 

226
00:13:52,720 --> 00:13:56,240
to the token holders, 
distributed to the makers 

227
00:13:56,240 --> 00:13:59,640
instead of takers, you know, 
prioritize cancels instead of 

228
00:14:00,320 --> 00:14:03,480
other orders. 
So a bunch of whatever they want

229
00:14:03,480 --> 00:14:05,800
to do, I want to leave that to 
the application layer. 

230
00:14:06,160 --> 00:14:10,960
And this is I think where Max 
Resnick and I like really mind 

231
00:14:10,960 --> 00:14:16,400
melded because at a gut level, 
I, I thought that we need 

232
00:14:16,400 --> 00:14:21,360
multiple block producers at the 
same time to create a dynamic 

233
00:14:21,360 --> 00:14:25,000
market that's competitive for 
people to accept these 

234
00:14:25,000 --> 00:14:28,320
transactions. 
And he kind of came, came for a 

235
00:14:28,320 --> 00:14:32,600
from a more economics research 
angle where he saw that if you 

236
00:14:32,600 --> 00:14:36,000
don't have multiple proposers, 
then applications cannot really 

237
00:14:36,000 --> 00:14:40,040
build these value capturing 
systems at all because the 

238
00:14:40,040 --> 00:14:42,680
validator will be able to 
effectively censor. 

239
00:14:42,680 --> 00:14:47,440
And if you, if you're censoring 
all the inputs that are going 

240
00:14:47,440 --> 00:14:50,480
into this application specific 
sequencing thing, then you can 

241
00:14:50,480 --> 00:14:53,480
effectively control the fees 
that the app sets anyways. 

242
00:14:53,880 --> 00:14:56,640
So what you need is like you 
need both of those pieces. 

243
00:14:56,640 --> 00:14:59,440
You need the hooks and the 
system for apps to be able to 

244
00:14:59,800 --> 00:15:03,680
set their own fees. 
And you need the competition 

245
00:15:03,680 --> 00:15:08,440
between block producers. 
And I'm 100% on board with all 

246
00:15:08,440 --> 00:15:11,520
those changes, even though on 
the surface they seem to give up

247
00:15:11,520 --> 00:15:12,960
some of the economics of the 
apps. 

248
00:15:13,280 --> 00:15:17,000
But the goal is if we have all 
the apps in one giant system, 

249
00:15:17,320 --> 00:15:20,920
the economics between all the 
cross application arbitrages are

250
00:15:20,920 --> 00:15:22,840
going to be way more than 
enough. 

251
00:15:24,000 --> 00:15:29,200
So with regards to MEVI think 
you've always had, you know, in 

252
00:15:29,200 --> 00:15:32,080
many ecosystems people have been
like, oh, MEV is a bad thing. 

253
00:15:32,080 --> 00:15:35,520
You need to minimize MEVI think 
you've always had a a more 

254
00:15:35,680 --> 00:15:39,840
positive view on MEV or like how
do you view MEV and how do you 

255
00:15:39,840 --> 00:15:42,320
think ME VS going to develop 
with those changes in the 

256
00:15:42,320 --> 00:15:45,080
future? 
A market maker submitting their 

257
00:15:45,080 --> 00:15:48,080
cancel before everyone else is 
MEV. 

258
00:15:49,000 --> 00:15:51,800
They're they're getting priority
access to state the head of 

259
00:15:51,800 --> 00:15:55,760
everyone else, they're paying 
for it to the exchange or to the

260
00:15:55,840 --> 00:16:01,480
whoever right that is MEV. 
But that creates better markets 

261
00:16:01,480 --> 00:16:04,400
because then the market makers 
can have tighter spreads. 

262
00:16:05,000 --> 00:16:10,440
So my feeling with MEV was that 
we need to maximize competition 

263
00:16:10,680 --> 00:16:15,040
so users always have the option 
to go to the best source for 

264
00:16:15,040 --> 00:16:18,480
their trade. 
And whether that means that the 

265
00:16:18,480 --> 00:16:22,560
validator is maximum sandwiching
and I'm giving everybody a 

266
00:16:22,560 --> 00:16:25,440
rebate, that could be one model 
that actually works. 

267
00:16:25,840 --> 00:16:28,760
That's fine as long as it's 
competitive and the users can 

268
00:16:28,760 --> 00:16:31,160
make that decision. 
And I suspect that each 

269
00:16:31,160 --> 00:16:33,720
individual users are likely to 
make that decision unless 

270
00:16:33,720 --> 00:16:36,560
they're pro. 
But like Phantom that wants to 

271
00:16:36,560 --> 00:16:40,240
serve the best possible 
blockchain to their users, 

272
00:16:40,640 --> 00:16:43,440
that's competing with Sol. 
Flare with Backpack will make 

273
00:16:43,440 --> 00:16:47,280
the informed decision to go with
a particular solution for how 

274
00:16:47,280 --> 00:16:48,920
they route their transactions 
and stuff. 

275
00:16:49,120 --> 00:16:51,680
But we need competition for 
that, for all that to work out. 

276
00:16:52,080 --> 00:16:56,920
So my view is that like the 
stuff isn't all that different 

277
00:16:56,920 --> 00:17:02,320
than a you're I'm selling block 
space, I'm buying block space. 

278
00:17:02,920 --> 00:17:05,880
For me to get the best offer, I 
need a healthy market of buyers 

279
00:17:05,880 --> 00:17:08,359
and sellers that that's kind of 
the basics that we need. 

280
00:17:09,119 --> 00:17:15,319
So in Ethereum proposed a 
builder separation, right was 

281
00:17:15,319 --> 00:17:18,880
like chosen a few years ago and 
it's it's the state today. 

282
00:17:19,720 --> 00:17:23,079
What do you think about Solana? 
Do you think we will also end up

283
00:17:23,079 --> 00:17:26,119
with proposed a builder 
separation and is is it 

284
00:17:26,119 --> 00:17:31,480
something desirable? 
I don't know if there's anything

285
00:17:31,480 --> 00:17:33,600
we need to enshrine for that to 
work. 

286
00:17:35,560 --> 00:17:37,280
Like it's kind of happening 
right now. 

287
00:17:37,400 --> 00:17:40,640
I don't, I don't know if there's
changes to the like if you need 

288
00:17:40,640 --> 00:17:44,360
like enshrined bundles, I don't 
have any objections to those. 

289
00:17:44,920 --> 00:17:48,880
What I do care about is 
concurrent block producers. 

290
00:17:48,880 --> 00:17:52,640
So multiple concurrent proposers
or multiple concurrent leaders 

291
00:17:52,960 --> 00:17:58,160
that we have like 2 validators, 
1 in Singapore, one in New York 

292
00:17:58,800 --> 00:18:01,920
that are running there that are 
both accepting transactions. 

293
00:18:01,960 --> 00:18:05,240
And the user can has the option,
do I send to the closest one in 

294
00:18:05,240 --> 00:18:08,000
New York or maybe one that's 
further away that's offering a 

295
00:18:08,000 --> 00:18:11,400
better deal? 
And if I'm a market maker and I 

296
00:18:11,400 --> 00:18:16,880
need my cancel to to land, what 
that means is that I can send to

297
00:18:16,880 --> 00:18:19,320
the one that isn't censoring and
I can. 

298
00:18:19,880 --> 00:18:23,400
And the network the the actual 
enshrined protocol needs to 

299
00:18:23,400 --> 00:18:26,480
support an ordering mechanism 
where I can pay the network 

300
00:18:26,480 --> 00:18:29,880
within this block. 
I'm paying a fee to go first. 

301
00:18:30,680 --> 00:18:34,320
So does that make sense? 
Yeah, I think that's definitely 

302
00:18:34,320 --> 00:18:36,920
one of the topics. 
I know there's a huge focus for 

303
00:18:36,920 --> 00:18:40,240
you and and I think currently in
the Solana developer thing is 

304
00:18:40,240 --> 00:18:42,000
this multiple concurrent 
proposer. 

305
00:18:42,640 --> 00:18:48,520
So for you, the main reason why 
you want that is because you 

306
00:18:48,520 --> 00:18:52,120
want competition between 
validators and you want 

307
00:18:52,120 --> 00:18:56,480
basically less ability for 
validators to kind of, you know,

308
00:18:56,480 --> 00:19:01,560
gouge the users or like. 
It's also a beautiful thing 

309
00:19:01,560 --> 00:19:05,800
because this is a way for a 
truly decentralized global 

310
00:19:05,800 --> 00:19:11,640
blockchain to beat Stradfi, to 
beat NASDAQ on actual pricing. 

311
00:19:11,920 --> 00:19:16,040
And this is a very subtle thing 
that the changes here is that if

312
00:19:16,040 --> 00:19:21,080
like the how like you think of 
the network or any exchange or 

313
00:19:21,080 --> 00:19:23,760
any of these systems as 
reflecting of the world state 

314
00:19:24,280 --> 00:19:26,800
and it has, there's an error 
between that state and the real 

315
00:19:26,800 --> 00:19:29,320
world. 
And constantly people are trying

316
00:19:29,320 --> 00:19:31,400
to reduce the, that error by 
submitting trades. 

317
00:19:31,400 --> 00:19:33,920
They see something, a price 
that's offered, they have 

318
00:19:33,920 --> 00:19:36,760
information in the real world, 
they're trying to close that 

319
00:19:36,760 --> 00:19:40,000
that error. 
And if like some event happens 

320
00:19:40,000 --> 00:19:44,120
in Singapore and there's a local
leader there in Singapore, the 

321
00:19:44,120 --> 00:19:48,200
latency for me to submit that 
trade is much, much shorter than

322
00:19:48,200 --> 00:19:49,800
to send it all the way to New 
York. 

323
00:19:50,480 --> 00:19:55,280
So for Solana as a blockchain 
TQB with NASDAQ, we need a block

324
00:19:55,280 --> 00:19:58,600
producer in every spot in the 
world that has any economic 

325
00:19:58,600 --> 00:20:01,520
activity. 
So then the user can submit that

326
00:20:01,520 --> 00:20:03,640
transaction locally and cut that
latency. 

327
00:20:03,640 --> 00:20:06,160
But. 
I, I, I, I want to understand 

328
00:20:06,160 --> 00:20:12,160
that because, because, or at 
least in, in Ethereum you have 

329
00:20:12,160 --> 00:20:19,320
for an upcoming block, you have 
exactly 1 proposal and, and that

330
00:20:19,320 --> 00:20:22,360
one might sit in New York, they 
might sit in, in, in, in 

331
00:20:22,360 --> 00:20:25,160
Singapore. 
So in Solana it sounds different

332
00:20:25,160 --> 00:20:28,760
or or is is it still the same? 
Now that right now that's that's

333
00:20:28,760 --> 00:20:31,200
exactly how Solana works. 
But there's no reason why you 

334
00:20:31,200 --> 00:20:33,960
can't have two proposers or N. 
OK. 

335
00:20:34,040 --> 00:20:38,240
But then let's say, OK, so now 
on the same, yeah, slot height, 

336
00:20:38,240 --> 00:20:40,880
block height, you have now 2, 
one in New York, one in 

337
00:20:40,880 --> 00:20:44,120
Singapore. 
So now let's say they would have

338
00:20:44,160 --> 00:20:46,680
two conflicting transactions 
here in one. 

339
00:20:47,960 --> 00:20:50,160
Then how? 
How is this merged or how is 

340
00:20:50,160 --> 00:20:51,680
this resolved this this 
conflict? 

341
00:20:53,280 --> 00:20:57,840
There's a deterministic merge, 
so we need that it has to have 

342
00:20:57,840 --> 00:21:00,600
that property. 
And two, if I want to go first, 

343
00:21:00,600 --> 00:21:04,320
I should burn some soul to be 
ahead of somebody else. 

344
00:21:05,560 --> 00:21:09,080
It this merge will be on on the 
whole block level or an 

345
00:21:09,120 --> 00:21:11,400
individual state? 
Probably. 

346
00:21:11,400 --> 00:21:14,240
I mean, probably. 
You you can think of it as a 

347
00:21:14,240 --> 00:21:17,080
block that is a chunk of data, 
right? 

348
00:21:17,440 --> 00:21:20,400
One MB, 2 megabytes, and the 
first half is written by 

349
00:21:20,400 --> 00:21:23,600
proposer A, the second-half is 
written by proposer B. 

350
00:21:23,600 --> 00:21:27,440
The network receives the entire 
block and then has runs a 

351
00:21:27,440 --> 00:21:30,000
deterministic merge to compute 
the results. 

352
00:21:30,640 --> 00:21:33,520
I see. 
But you can have any number of 

353
00:21:33,520 --> 00:21:37,760
these proposers. 
The main constraint is basically

354
00:21:37,920 --> 00:21:43,000
we think we don't know until we 
test is how many shreds we can 

355
00:21:43,000 --> 00:21:46,720
propagate through the network, 
and shreds is our term for 

356
00:21:46,960 --> 00:21:48,800
erasure coded chunks of the 
block. 

357
00:21:49,840 --> 00:21:54,000
But, but it also means that if 
you if you hit, if the 

358
00:21:54,000 --> 00:21:57,880
transaction hits your local 
proposal at that moment, you do 

359
00:21:57,880 --> 00:22:01,200
not, you don't know exactly what
happens. 

360
00:22:01,200 --> 00:22:04,160
You then need to wait for kind 
of some second round. 

361
00:22:04,440 --> 00:22:06,720
Or is the merge round 
essentially to to? 

362
00:22:07,080 --> 00:22:09,000
It's not. 
It's not a round once you 

363
00:22:09,000 --> 00:22:11,680
receive the data from the. 
Yeah, that's right. 

364
00:22:11,680 --> 00:22:14,520
Then you can locally. 
Yeah, I see. 

365
00:22:14,640 --> 00:22:17,360
Yeah. 
So the network could effectively

366
00:22:18,040 --> 00:22:22,200
the latency there is isn't 
really lost because as soon as 

367
00:22:22,200 --> 00:22:25,760
the network receives the data, 
it can vote on confirming that 

368
00:22:25,760 --> 00:22:28,000
the data has landed. 
So as soon as you see the 

369
00:22:28,000 --> 00:22:31,360
confirmation, you can compute 
the results and you don't need 

370
00:22:31,360 --> 00:22:34,040
to wait for everybody to compute
the results and confirm that 

371
00:22:34,040 --> 00:22:36,880
because that part is 
deterministic. 

372
00:22:37,840 --> 00:22:41,520
You obviously like, if you're a 
professional like system like 

373
00:22:41,520 --> 00:22:45,360
that's like a custodian or or a 
bridge, you might want to run 

374
00:22:45,760 --> 00:22:49,960
different boxes with different 
one fire dancer, one Anza. 

375
00:22:50,360 --> 00:22:52,560
Make sure all of them agree on 
the results. 

376
00:22:52,560 --> 00:22:55,160
Essentially. 
Essentially the blockchain would

377
00:22:55,160 --> 00:22:59,920
then become a a deck, right? 
Or I mean that what is directed 

378
00:23:00,080 --> 00:23:03,720
a cyclic graph? 
No, it's different from a DAG. 

379
00:23:04,800 --> 00:23:10,440
Dags resolve their ordering 
based on the next, well producer

380
00:23:10,440 --> 00:23:13,200
that then decides the ordering 
of the previous transactions. 

381
00:23:13,960 --> 00:23:16,200
This you have literally 
concurrent leaders. 

382
00:23:16,240 --> 00:23:20,360
It's no different. 
It it is like leader one writes 

383
00:23:20,360 --> 00:23:23,680
the first page, leader 2 writes 
the second page, and then you 

384
00:23:23,680 --> 00:23:27,080
mix them together. 
The the shuffling here is 

385
00:23:27,080 --> 00:23:30,040
enshrined and deterministic, and
that's different from the tag. 

386
00:23:30,240 --> 00:23:32,240
It's not dependent on the next 
producer. 

387
00:23:32,680 --> 00:23:36,600
So if if you have these two 
proposers and let's say there's 

388
00:23:36,600 --> 00:23:43,000
some arbitrage opportunity and 
now people they've both 

389
00:23:43,000 --> 00:23:46,840
proposals put in transactions 
that both try to capture the 

390
00:23:46,840 --> 00:23:51,640
same arbitrage opportunity, then
basically it will get merged and

391
00:23:51,640 --> 00:23:56,200
then whichever is the first one 
actually gets executed. 

392
00:23:56,760 --> 00:24:00,040
Yep, so the highest burned one 
the the one with the highest 

393
00:24:00,040 --> 00:24:02,240
burned for fees will execute 
first. 

394
00:24:02,440 --> 00:24:04,560
OK, OK, OK. 
What's the? 

395
00:24:04,560 --> 00:24:09,200
Hardest thing about making 
multiple concurrent proposals 

396
00:24:09,200 --> 00:24:09,880
happen though. 
What? 

397
00:24:09,880 --> 00:24:11,560
What are the problems that you 
need to solve? 

398
00:24:13,480 --> 00:24:16,520
The stability of consensus 
basically like it's just the 

399
00:24:16,520 --> 00:24:23,560
implementation is like prone to 
outages I would say, but isn't. 

400
00:24:23,560 --> 00:24:26,880
I don't think it's design wise 
any worse for the worst case 

401
00:24:27,240 --> 00:24:31,920
because consensus mechanisms all
deal with a single leader that 

402
00:24:31,920 --> 00:24:34,880
produces two different blocks. 
They all have to resolve that. 

403
00:24:36,120 --> 00:24:37,680
Even if you slash that leader 
right? 

404
00:24:37,680 --> 00:24:40,840
Do you still don't want to have 
an outage in case that you have 

405
00:24:40,840 --> 00:24:43,200
a bad leader? 
So the worst thing that you want

406
00:24:43,200 --> 00:24:47,640
to do is have a, is have a 
performance segregation and 

407
00:24:47,640 --> 00:24:50,160
slashing for performance 
segregation is fine because then

408
00:24:50,160 --> 00:24:53,400
you reduce them in practice. 
But you cannot, you still have 

409
00:24:53,400 --> 00:24:56,680
to deal with it no matter what. 
So in an environment where you 

410
00:24:56,680 --> 00:25:02,800
have two leaders, the the 
network will see four different 

411
00:25:02,800 --> 00:25:07,160
views potentially of the results
of the block only leader A, only

412
00:25:07,240 --> 00:25:12,320
leader B, neither or both. 
So and the deterministic shuffle

413
00:25:12,320 --> 00:25:14,240
would be different for each one,
right? 

414
00:25:14,400 --> 00:25:17,600
If you only see data from leader
A, then you just stick leader 

415
00:25:17,600 --> 00:25:19,160
A's block. 
If you see both, then you 

416
00:25:19,160 --> 00:25:20,640
shuffle. 
If you see neither, then you 

417
00:25:20,640 --> 00:25:23,920
skip. 
And this is the complex part. 

418
00:25:25,080 --> 00:25:28,000
What you want to do is you want 
to make sure that there is no 

419
00:25:28,000 --> 00:25:31,240
partition in these views. 
So every time they vote, they 

420
00:25:31,240 --> 00:25:34,160
take the happy path. 
It doesn't matter what partition

421
00:25:34,160 --> 00:25:36,640
they see, as long as everybody 
in the network sees the same 

422
00:25:36,640 --> 00:25:39,720
thing. 
If everybody sees that leader B 

423
00:25:39,720 --> 00:25:43,200
failed, that's great. 
It means that they all agree on 

424
00:25:43,200 --> 00:25:46,880
the vote and that you continue 
doing the on the happy path of, 

425
00:25:46,920 --> 00:25:52,280
of the consensus rules. 
And Solana, like we, we built 

426
00:25:52,280 --> 00:25:55,040
our consensus. 
It's very complicated and a pain

427
00:25:55,040 --> 00:26:00,000
in the ass to work with, but the
properties that it has that 

428
00:26:00,400 --> 00:26:04,120
previous systems didn't have is 
that it was bandwidth efficient,

429
00:26:04,240 --> 00:26:08,160
that you have a block on every 
point in time, that there was no

430
00:26:08,160 --> 00:26:11,360
stalls waiting for rounds to to 
finish before the next block 

431
00:26:11,360 --> 00:26:12,600
starts. 
You start. 

432
00:26:13,360 --> 00:26:17,480
We now see systems like I think 
Aptos and Zui have gotten that 

433
00:26:17,480 --> 00:26:19,800
to work with more modern 
consensus algorithms. 

434
00:26:20,040 --> 00:26:25,640
It's a whole team from Zurich 
optimizing and basically getting

435
00:26:25,640 --> 00:26:30,120
rid of all my technical debt to 
to have like a a better version 

436
00:26:30,120 --> 00:26:34,840
of of consensus on Solana. 
And again, we can maintain a 

437
00:26:34,840 --> 00:26:37,840
bandwidth efficiency and we can 
deal with all the partitions. 

438
00:26:39,480 --> 00:26:44,400
Then talking about yeah, 
efficiencies, what are currently

439
00:26:44,600 --> 00:26:47,960
the bottlenecks or yeah, what, 
what's currently the bottleneck 

440
00:26:48,320 --> 00:26:56,280
for scaling in Salon? 
It is basically you've seen like

441
00:26:56,280 --> 00:27:01,080
I think like Eclipse and a bunch
of other kind of Solana SVM base

442
00:27:01,080 --> 00:27:04,560
layer twos to tune up the 
compute units. 

443
00:27:06,120 --> 00:27:08,680
So basically the the bottlenecks
is making. 

444
00:27:08,680 --> 00:27:12,760
Sure that you need to you need 
to help me here so say again. 

445
00:27:13,040 --> 00:27:15,840
There's a whole bunch of not 
Solana layer twos, but layer 

446
00:27:15,840 --> 00:27:20,320
twos that use SVM. 
Some may even be Solana layer 

447
00:27:20,320 --> 00:27:21,800
twos. 
I don't even know what what the 

448
00:27:21,800 --> 00:27:24,640
marketing, I, I don't know. 
I don't know. 

449
00:27:24,640 --> 00:27:27,520
I I don't even know which state 
route they're looking at. 

450
00:27:27,520 --> 00:27:30,040
Is it Ethereums or Solanas? 
It doesn't matter. 

451
00:27:31,200 --> 00:27:34,360
I treat them all as competitors 
'cause if the fees accrued, they

452
00:27:34,360 --> 00:27:37,800
are not accruing on mainnet, 
they're not paying for mainnet 

453
00:27:37,800 --> 00:27:41,240
development. 
So and they're fine. 

454
00:27:41,240 --> 00:27:43,160
We're all, it's all, it's all 
good. 

455
00:27:43,160 --> 00:27:44,760
We're all building open source 
software. 

456
00:27:44,760 --> 00:27:46,480
So it's like Red Hat versus 
Ubuntu. 

457
00:27:46,480 --> 00:27:50,480
It's, it's healthy competition. 
But they've been able to 

458
00:27:50,480 --> 00:27:55,080
increase their block capacity, I
think by factors of 5 to 10. 

459
00:27:56,880 --> 00:28:01,560
So it is basically the blockers 
are is just testing. 

460
00:28:02,000 --> 00:28:08,520
It's just making sure that when 
we, when ONS are in Fire Dancer,

461
00:28:08,520 --> 00:28:14,440
increase the capacity that there
isn't some, I call them like 

462
00:28:14,680 --> 00:28:16,080
they're denial of service 
attacks. 

463
00:28:16,080 --> 00:28:20,920
There isn't some metering 
problem in the VM or in the 

464
00:28:20,920 --> 00:28:23,640
block or whatever that an 
attacker can exploit and create 

465
00:28:23,640 --> 00:28:27,160
a block that takes 10 times more
to process than normal. 

466
00:28:27,440 --> 00:28:30,560
But these are basically like the
the the worst case kind of 

467
00:28:30,560 --> 00:28:32,800
scenarios that they're pain in 
the ass to find. 

468
00:28:33,120 --> 00:28:36,040
Let me just repeat because I'm 
not that deep into Solana. 

469
00:28:36,040 --> 00:28:39,600
So you're saying yes, there are.
There are versions essentially 

470
00:28:39,600 --> 00:28:44,760
of Solana, the SVM, that already
run at 5X capacity of what 

471
00:28:44,920 --> 00:28:48,400
Solana does right now, and it 
kind of works, but you are 

472
00:28:48,560 --> 00:28:51,480
slightly more conservative and 
and. 

473
00:28:51,520 --> 00:28:54,320
We have to be right. 
Those are not decentralized, 

474
00:28:54,320 --> 00:28:57,880
right? 
They're basically roll up like. 

475
00:28:58,520 --> 00:29:02,040
But even doesn't matter there 
earlier they can take more risk.

476
00:29:02,040 --> 00:29:05,040
That's the difference. 
If if we if we were just 

477
00:29:05,040 --> 00:29:07,680
starting out, I would I would 
tune the network to 10X 

478
00:29:07,680 --> 00:29:12,320
performance and deal with the 
fires like that's the 

479
00:29:12,320 --> 00:29:16,560
difference. 
So I mean the other, the other 

480
00:29:16,560 --> 00:29:20,280
point you were making is that 
you would say kind of L2's are 

481
00:29:21,000 --> 00:29:25,040
not really interesting you would
say to Solana from from from an 

482
00:29:25,040 --> 00:29:28,760
economic or fee perspective. 
So, so you're. 

483
00:29:28,880 --> 00:29:31,920
Interesting to me, yes, those 
people that they're interesting 

484
00:29:31,920 --> 00:29:35,320
too and that's fine. 
But what I want is mainland to 

485
00:29:35,320 --> 00:29:37,280
succeed, right? 
So to me what matters is 

486
00:29:37,280 --> 00:29:39,440
activity on mainland trading and
mainland. 

487
00:29:40,760 --> 00:29:46,400
So essentially the whole idea 
that I kind of kind of the 

488
00:29:46,600 --> 00:29:50,920
Ethereum idea that somehow you 
would provide BLOB space or kind

489
00:29:50,920 --> 00:29:54,600
of data availability or 
transaction ordering and then 

490
00:29:54,600 --> 00:29:57,520
other use it for other space 
that that you don't. 

491
00:29:57,520 --> 00:30:00,600
Ordering. 
If you could do ordering then 

492
00:30:00,600 --> 00:30:07,040
yes, but there isn't. 
I think the base roll up thing 

493
00:30:07,040 --> 00:30:13,440
is still not fully defined and 
if the chain is doing ordering 

494
00:30:13,960 --> 00:30:19,600
and DA the based roll up the 
only difference is then like a 

495
00:30:19,600 --> 00:30:21,600
different virtual machine or 
something like that. 

496
00:30:22,280 --> 00:30:23,960
I, I, I do very much agree with 
you. 

497
00:30:23,960 --> 00:30:27,000
So there. 
So I am also in the, I'm kind of

498
00:30:27,000 --> 00:30:31,080
in the Etherium camp of if, if 
roll ups, then it, it should be 

499
00:30:31,080 --> 00:30:34,640
based roll ups because I feel 
like if Etherium is trying to 

500
00:30:34,640 --> 00:30:38,640
sell something, it cannot just 
be generic data availability 

501
00:30:38,640 --> 00:30:41,320
because that's a commodity. 
It needs to be specifically 

502
00:30:41,320 --> 00:30:44,280
transaction ordering. 
We we already have based roll 

503
00:30:44,280 --> 00:30:48,200
ups done like there's there's 
already like ZK proved Merkel 

504
00:30:48,200 --> 00:30:54,040
trees or like classically proved
Merkel trees book leaves for for

505
00:30:54,040 --> 00:30:55,760
spade. 
To me, the interesting thing 

506
00:30:55,760 --> 00:31:00,400
about based roll ups is that 
they kind of still have this 

507
00:31:00,680 --> 00:31:03,760
atomic composability. 
Or you can have atomic 

508
00:31:03,760 --> 00:31:06,280
transactions that touch A1 and 
A2 state. 

509
00:31:06,680 --> 00:31:11,080
And, and the advantage is I, I, 
I think it's fair. 

510
00:31:11,520 --> 00:31:14,720
It's fair to say, OK, you still 
have some validators that have 

511
00:31:14,800 --> 00:31:16,480
all the state. 
And then it almost doesn't 

512
00:31:16,480 --> 00:31:19,160
matter whether that's on the L2 
or on the L1. 

513
00:31:19,480 --> 00:31:25,440
But if you care about being able
to have lower performance or it 

514
00:31:25,440 --> 00:31:29,360
kind of have validators, I mean,
well, here's my debt note 

515
00:31:29,360 --> 00:31:33,160
sitting next to me that runs 
Ethereum and I can still do this

516
00:31:33,160 --> 00:31:36,480
from home. 
If you care about that, then it 

517
00:31:36,480 --> 00:31:39,840
does make sense to say OK, some 
state that kind of exists, but 

518
00:31:39,840 --> 00:31:44,560
it doesn't have to be available 
to anyone who's who's running a 

519
00:31:44,560 --> 00:31:48,480
validator on the other one. 
There's already sort of stuff 

520
00:31:48,480 --> 00:31:52,600
like that running on Solana. 
So Metaplex built this thing 

521
00:31:52,600 --> 00:31:54,880
called compression. 
I don't know if you saw this 

522
00:31:54,880 --> 00:31:59,640
terrible marketing name, I came 
off the bat, but it's basically 

523
00:31:59,640 --> 00:32:01,560
a Merkel. 
It's a Merkel root that's on 

524
00:32:01,560 --> 00:32:06,840
chain, and you can atomically 
prove the data exists in this 

525
00:32:06,840 --> 00:32:11,040
tree and another piece of data 
exists in a totally separate 

526
00:32:11,040 --> 00:32:15,320
tree, push them to the L1 
state-run a computation on them 

527
00:32:15,320 --> 00:32:18,200
through a program like a token 
swap, and then push them back 

528
00:32:18,200 --> 00:32:20,920
into the trees. 
All of this in a single atomic 

529
00:32:20,920 --> 00:32:25,320
transaction. 
So the state that is effectively

530
00:32:25,320 --> 00:32:29,680
cold can be offloaded and run 
programmatically in these Merkel

531
00:32:29,680 --> 00:32:31,960
trees. 
And the primary thing that 

532
00:32:31,960 --> 00:32:36,880
they're used for is like NFT, 
like you, you mint your 20,000 

533
00:32:36,880 --> 00:32:39,960
NF TS. 
You can instantly like mint them

534
00:32:39,960 --> 00:32:44,440
in one batch or one Merkel tree.
And you just register the leaves

535
00:32:44,440 --> 00:32:46,880
with the chain so wallets and 
stuff can pick him up. 

536
00:32:47,320 --> 00:32:51,680
And there's now ZK based 
approach to make the proof 

537
00:32:51,680 --> 00:32:53,960
smaller and and a bit more 
composable. 

538
00:32:54,240 --> 00:32:57,120
But that part is is like the 
easy part. 

539
00:32:57,120 --> 00:33:02,720
I think the based roll up is a 
bit more a a bigger piece of 

540
00:33:02,720 --> 00:33:06,480
technology than that. 
It involves developers defining 

541
00:33:06,480 --> 00:33:09,720
their virtual machine and the 
the state transition function 

542
00:33:09,720 --> 00:33:13,800
that connects their VM to the 
state root on the L1. 

543
00:33:16,240 --> 00:33:21,760
My problem with those is that 
there's just no need for that 

544
00:33:21,760 --> 00:33:26,840
many re amps like I'm sorry. 
Frankly, frankly, I, yeah, 

545
00:33:26,840 --> 00:33:30,640
frankly I I would also kind of 
for the base roll up say just do

546
00:33:30,640 --> 00:33:33,480
EVM and. 
Kind of just what's the point to

547
00:33:33,480 --> 00:33:37,360
have like a dozen different EVM 
based roll ups? 

548
00:33:37,560 --> 00:33:43,240
The the point might be to reduce
to kind of still allow people 

549
00:33:43,240 --> 00:33:50,760
to, I mean run relatively 
lightweight L1 validators and 

550
00:33:50,760 --> 00:33:54,280
kind of say if you if you want 
to do the full thing, then you 

551
00:33:54,280 --> 00:33:58,640
run the L1 and and the L twos 
and have the full state 

552
00:33:58,640 --> 00:34:01,720
available. 
But how's that any any different

553
00:34:01,720 --> 00:34:05,760
from like I have a like a 
program that has like a 

554
00:34:06,640 --> 00:34:09,840
dedicated circuit, like AZK 
circuit, and I just proved that 

555
00:34:09,840 --> 00:34:13,639
program like I don't need any VM
general purpose CVMI have like 

556
00:34:13,639 --> 00:34:21,159
my my minimize whatever the like
Lego piece of of a smart 

557
00:34:21,159 --> 00:34:24,040
contract. 
I just prove that smart contract

558
00:34:24,040 --> 00:34:27,120
only. 
And now I have a way to route 

559
00:34:27,120 --> 00:34:29,320
data through that thing through 
the L1. 

560
00:34:30,120 --> 00:34:33,520
So you have your transaction 
approves the state calls the 

561
00:34:33,520 --> 00:34:36,719
contract, right with approve 
calls another one and then like 

562
00:34:36,719 --> 00:34:41,800
a a series and then it's done. 
So that's effectively like the 

563
00:34:41,800 --> 00:34:44,360
old stateless like design, 
right? 

564
00:34:44,360 --> 00:34:47,560
Like like what? 
What is the difference between 

565
00:34:47,560 --> 00:34:50,320
that and the base roll up? 
Like why? 

566
00:34:50,320 --> 00:34:52,800
Why aren't base roll ups just 
simply smart contracts? 

567
00:34:54,159 --> 00:34:58,360
I think you can view it as that.
Yeah, then like those already in

568
00:34:58,360 --> 00:35:05,320
fact kind of exist with some 
traction like they're useful for

569
00:35:05,760 --> 00:35:11,920
I think like large like if 
you're trying to air drop to a 

570
00:35:11,920 --> 00:35:15,440
very large user base and that 
kind that kind of thing. 

571
00:35:15,840 --> 00:35:19,800
People have found tractions with
that, but they haven't found 

572
00:35:19,800 --> 00:35:23,680
traction with like like what 
what I think is, is kind of 

573
00:35:23,680 --> 00:35:26,880
interesting that you see that 
works well is like Jupiter, 

574
00:35:28,000 --> 00:35:32,680
Radium, like even pump, all 
these things are all really, 

575
00:35:32,680 --> 00:35:36,480
really tied together and the 
execution and you can see in the

576
00:35:36,480 --> 00:35:39,480
transaction that a single 
transaction will hit like 5 

577
00:35:39,480 --> 00:35:41,760
different markets all at the 
same time. 

578
00:35:42,000 --> 00:35:46,920
And we haven't seen like anyone 
be able to build AZK based or 

579
00:35:46,920 --> 00:35:50,160
something that is truly off 
chain that still plugs into the 

580
00:35:50,160 --> 00:35:52,360
atomic execution piece for 
trading. 

581
00:35:53,880 --> 00:35:58,360
So let's talk about fired answer
and sort of Solana clients, 

582
00:35:58,360 --> 00:36:00,520
right? 
So fired answer's been in the 

583
00:36:00,520 --> 00:36:05,680
works for a long time aiming to,
you know, speed up and remove a 

584
00:36:05,680 --> 00:36:07,840
lot of performance bottlenecks 
in the client. 

585
00:36:08,920 --> 00:36:12,520
What are your thoughts on, you 
know what the impact will be on 

586
00:36:12,520 --> 00:36:18,400
the network and you see in the 
future you want to see a bunch 

587
00:36:18,400 --> 00:36:21,560
of different clients running in 
maintenance at the same time? 

588
00:36:23,640 --> 00:36:28,640
Do we need a bunch? 
I think 4 is what people it's 

589
00:36:28,640 --> 00:36:31,600
like 4 or 5 is like you kind of 
need. 

590
00:36:32,040 --> 00:36:35,000
Technically you should have 5 
for BFT so you can do 

591
00:36:35,000 --> 00:36:37,680
maintenance on one and then you 
still have reliability of 1 

592
00:36:37,680 --> 00:36:39,440
going down without a liveness 
failure. 

593
00:36:40,840 --> 00:36:45,680
That's like the dream, but the 
you just get an astronomical 

594
00:36:46,680 --> 00:36:52,080
improvement on safety when you 
have two like because it, it's 

595
00:36:52,080 --> 00:36:55,480
just such a, this is the, the 
thing that keeps me up at night 

596
00:36:55,480 --> 00:36:59,920
is like some bug that auditors 
and testing and all that stuff 

597
00:36:59,920 --> 00:37:02,080
missed. 
That's a critical vulnerability.

598
00:37:02,080 --> 00:37:04,760
That's a zero day that could 
steal everyone's funds. 

599
00:37:05,080 --> 00:37:07,800
That's the scary part. 
You have two separate teams that

600
00:37:07,800 --> 00:37:10,440
built the same code. 
It's very unlikely that they 

601
00:37:10,440 --> 00:37:14,440
would have the same bug in both 
code bases that can be executed 

602
00:37:14,640 --> 00:37:17,720
the same way at the same time. 
So you have some redundancy 

603
00:37:17,720 --> 00:37:20,600
there that that's just really, 
really critical for these 

604
00:37:20,600 --> 00:37:24,520
systems. 
But if fired answer now is, you 

605
00:37:24,520 --> 00:37:30,200
know can process more 
transactions then I mean I would

606
00:37:30,200 --> 00:37:33,680
expect that all of the 
validators will switch to that, 

607
00:37:33,680 --> 00:37:36,600
no, because they will earn more 
fees so. 

608
00:37:36,600 --> 00:37:39,800
No, it's the the limits of set 
network wise to make sure that 

609
00:37:39,800 --> 00:37:45,960
both clients can can run it. 
And Agave is not a slow client. 

610
00:37:45,960 --> 00:37:49,840
He can actually just you can 
literally just remove our limits

611
00:37:49,840 --> 00:37:51,920
and then run it at like 10X 
capacity. 

612
00:37:53,800 --> 00:37:57,560
Right now. 
There's no, the, the limits are 

613
00:37:57,560 --> 00:38:02,240
there to kind of slowly, like 
there's no fire to increase 

614
00:38:02,240 --> 00:38:06,960
block space because even like 
during the, the crazy, the worst

615
00:38:06,960 --> 00:38:12,880
case day with like Trump coin 
launching the fees, the median 

616
00:38:12,880 --> 00:38:16,080
fee was like 15 cents a 
transaction. 

617
00:38:16,080 --> 00:38:18,400
And this is when the network is 
doing 40 billion. 

618
00:38:18,720 --> 00:38:22,160
Now that's high. 
And if that was sustained, they 

619
00:38:22,160 --> 00:38:25,280
would become fire. 
But that being the worst case, 

620
00:38:26,120 --> 00:38:29,800
you know, like peak demand, that
was, you know, 10% of Nasdaq's 

621
00:38:29,800 --> 00:38:31,760
volume. 
That's actually really, really 

622
00:38:31,760 --> 00:38:35,080
good in terms of, in terms of 
fees. 

623
00:38:35,080 --> 00:38:41,200
So there isn't a fire. 
There is a like, there's a 

624
00:38:41,200 --> 00:38:44,640
reason to increase block space 
that I think is more long term. 

625
00:38:45,080 --> 00:38:48,320
And what I care more about is 
that like every release in bumps

626
00:38:48,320 --> 00:38:53,320
block space by 2040% versus them
getting 10X in two years. 

627
00:38:53,920 --> 00:38:58,400
Like as long as the developers 
are pushing themselves like, 

628
00:38:58,400 --> 00:39:01,240
hey, what is the, what is the 
bottleneck that is keeping them 

629
00:39:01,240 --> 00:39:03,720
up at night that could be 
exploited or whatever. 

630
00:39:03,720 --> 00:39:06,760
They write the test, they get 
comfortable with it, and then 

631
00:39:06,760 --> 00:39:11,040
they tune that parameter up. 
This is what I want to see more 

632
00:39:11,040 --> 00:39:15,720
so than like let's 10X and then 
see what breaks and have like a 

633
00:39:15,720 --> 00:39:20,760
bunch of weekends everyone has 
to go like fight fires. 

634
00:39:22,000 --> 00:39:25,360
You you mentioned the security 
improvements from having a 

635
00:39:25,440 --> 00:39:28,880
second client. 
So how would the network behave 

636
00:39:28,880 --> 00:39:32,200
in different scenarios? 
Let's say 10% of the validators 

637
00:39:32,200 --> 00:39:34,720
would run. 
Or let's say Fire Dance is new 

638
00:39:34,720 --> 00:39:38,760
and only 10% run it. 
We need more than 33% run by the

639
00:39:38,760 --> 00:39:42,560
minority clients, so some it 
doesn't matter where it's but as

640
00:39:42,560 --> 00:39:46,480
long as the the smallest client 
has more than 33% then the 

641
00:39:46,480 --> 00:39:48,360
network would halt. 
Right. 

642
00:39:48,360 --> 00:39:49,480
It would halt. 
OK, I see. 

643
00:39:50,200 --> 00:39:52,600
And that's OK. 
We're not at the area this. 

644
00:39:53,040 --> 00:39:54,360
Yeah, yeah. 
And you, you see this as 

645
00:39:54,360 --> 00:39:56,560
preferable. 
So you would say if, if, if 

646
00:39:56,560 --> 00:39:58,240
there is a buck, then it should 
halt. 

647
00:39:58,760 --> 00:40:01,320
Yeah. 
And people can quickly fix it 

648
00:40:01,320 --> 00:40:04,760
and it's a nega on everyone's 
face and it sucks and it should 

649
00:40:04,760 --> 00:40:08,200
never happen. 
And there's a lot of effort to 

650
00:40:08,200 --> 00:40:10,240
put in to make sure it never 
happens. 

651
00:40:10,920 --> 00:40:15,680
But if there is a exploit, then 
yeah, please halt like right 

652
00:40:15,680 --> 00:40:19,080
away. 
And then people can go fix it. 

653
00:40:19,160 --> 00:40:23,160
That that's the preferable 
outcome to anything else 'cause 

654
00:40:23,160 --> 00:40:25,280
like, I mean, if there's truly 
an exploit. 

655
00:40:26,600 --> 00:40:29,320
And you continue running the 
chain even if you allow like 

656
00:40:29,320 --> 00:40:32,480
define liquidations to run, 
they're mixed in with exploited 

657
00:40:32,480 --> 00:40:37,120
transactions. 
You fucking that state, the 

658
00:40:37,120 --> 00:40:39,840
resulting that state is a 
nightmare. 

659
00:40:40,360 --> 00:40:44,160
It's like it's worse than a 18 
hour average or whatever. 

660
00:40:44,760 --> 00:40:48,600
Like as as Ethereum folks, I 
don't know if you're around for 

661
00:40:48,600 --> 00:40:52,080
the Dow hack. 
There was the only reason they 

662
00:40:52,080 --> 00:40:56,480
were able to deal with the the 
Dow with the state, like with a 

663
00:40:56,480 --> 00:40:58,680
hard fork is because it was 
locked. 

664
00:40:58,760 --> 00:41:01,360
All that all those funds were 
locked up in a smart contract 

665
00:41:01,360 --> 00:41:04,640
that couldn't exit once if they 
started getting mixed with a 

666
00:41:04,640 --> 00:41:08,240
whole bunch of things like it's 
just impossible to unravel. 

667
00:41:08,240 --> 00:41:11,560
You have like somebody launches 
a meme coin, the attacker 

668
00:41:11,560 --> 00:41:14,920
launches a meme coin, buys it 
with the funds it's mixed in 

669
00:41:14,920 --> 00:41:17,800
with a whole bunch of liquidity.
Like you cannot like, really 

670
00:41:17,960 --> 00:41:19,760
untangle that in any sane way 
and. 

671
00:41:20,480 --> 00:41:22,560
You'd have to like actually. 
Roll back. 

672
00:41:22,760 --> 00:41:26,760
I think you know and reset from 
an earlier state probably. 

673
00:41:27,240 --> 00:41:31,480
Yeah, to me that is far worse 
than just a hard line is failure

674
00:41:33,000 --> 00:41:38,080
because that like not you can't 
roll back the real world. 

675
00:41:38,080 --> 00:41:40,920
There's action that's taking in 
the real world based on the 

676
00:41:40,920 --> 00:41:45,840
chain state, like Circle is 
sending funds out or based on 

677
00:41:45,840 --> 00:41:48,360
like mints, like mint and burns,
right? 

678
00:41:48,880 --> 00:41:52,040
You can't like tell them, hey, 
go rollback his transfers. 

679
00:41:53,640 --> 00:41:56,840
It's better to halt this. 
This is like I, I think in all 

680
00:41:56,840 --> 00:41:59,400
these cases, like it's basically
better to halt. 

681
00:42:00,520 --> 00:42:05,640
I think once you have 4 clients,
you could say that like the 

682
00:42:05,640 --> 00:42:11,320
probability of a bug in three is
so much smaller than the 

683
00:42:11,320 --> 00:42:16,320
probability in, you know, bug in
two that it's fine for one to be

684
00:42:16,320 --> 00:42:18,560
down. 
And then you can do this kind of

685
00:42:18,560 --> 00:42:21,120
maintain some lineness while 
while one is down and and 

686
00:42:21,120 --> 00:42:24,600
rotate. 
But yeah, the the terrifying 

687
00:42:24,600 --> 00:42:27,120
this is the this is like the 
worst nightmare. 

688
00:42:30,480 --> 00:42:34,800
Well, I, I, I want to, I want to
ask another maybe a little bit 

689
00:42:34,800 --> 00:42:38,120
more on the scaling thing before
we go to security. 

690
00:42:39,200 --> 00:42:42,000
What do you think is, is 
possible here? 

691
00:42:42,040 --> 00:42:46,000
Like if you think of like, I 
don't know, 5-10 years ahead, 

692
00:42:46,560 --> 00:42:50,920
where do you want to see Solana 
in terms of throughput? 

693
00:42:50,920 --> 00:42:57,400
And do you think it's feasible 
to basically have Solana scale 

694
00:42:57,400 --> 00:43:01,000
to such a level that it can 
absorb, you know, kind of like 

695
00:43:01,000 --> 00:43:04,760
or you can satisfy like all the 
demand of the world in terms of 

696
00:43:04,760 --> 00:43:09,000
block space? 
Our blocks right now are like 2 

697
00:43:09,000 --> 00:43:13,240
to 4 megabytes in size. 
The New York Times website is 

698
00:43:13,240 --> 00:43:19,960
like 20 megabytes, but my my 
very mediocre goal is to get 

699
00:43:20,240 --> 00:43:22,840
blocks to the size of the New 
York Times website. 

700
00:43:23,240 --> 00:43:27,880
Like you don't even need the 
crazy 2D erasure code sampling 

701
00:43:27,880 --> 00:43:31,160
for light clients when your 
blocks are the size of the New 

702
00:43:31,160 --> 00:43:33,640
York Times website. 
People can just download full 

703
00:43:33,640 --> 00:43:37,160
blocks to their phone and nobody
like you. 

704
00:43:37,280 --> 00:43:39,960
You don't need these like next 
generation technologies yet. 

705
00:43:40,280 --> 00:43:47,960
So, and that would be like a 10X
increase and is, is that enough 

706
00:43:47,960 --> 00:43:53,120
to handle the, the entire world?
I think somewhere between 10:10 

707
00:43:53,120 --> 00:43:57,840
X to like my, my belief is that 
like you look at Google, they 

708
00:43:59,680 --> 00:44:03,040
when the their estimated 
searches per second is somewhere

709
00:44:03,040 --> 00:44:07,360
like around 50,000 to 80,000. 
That's a fully globally scaled 

710
00:44:07,640 --> 00:44:11,320
web application that is fully 
permeated the entire world that 

711
00:44:11,320 --> 00:44:16,720
people use constantly and people
use finance a lot less often 

712
00:44:16,720 --> 00:44:21,000
than not. 
So like 100,000 TPS in a single 

713
00:44:21,000 --> 00:44:25,840
O1 would cover the 99% of the 
most important financial 

714
00:44:25,840 --> 00:44:30,080
transactions for sure. 
So somewhere between like, you 

715
00:44:30,080 --> 00:44:35,040
know, 1-10 X and another 10 XI. 
Think that is actually probably 

716
00:44:35,320 --> 00:44:40,240
as far as crypto needs to scale.
It sucks to put limits on it and

717
00:44:40,240 --> 00:44:46,320
people feel like oh you're being
so pessimistic but like I pray 

718
00:44:46,320 --> 00:44:49,880
that all my competitors are 
designing for infinite demand. 

719
00:44:51,640 --> 00:44:54,600
That is like the worst, worst 
engineering trap. 

720
00:44:55,680 --> 00:44:58,840
And I don't even tell lots of 
people to 10X the capacity. 

721
00:44:58,840 --> 00:45:01,080
What I tell them is like just 
two X at this year. 

722
00:45:01,360 --> 00:45:04,320
Just think incremental 
improvements a year that you can

723
00:45:04,320 --> 00:45:07,160
ship confidently and then 2X it 
again next year. 

724
00:45:07,160 --> 00:45:10,520
And just like that, that's so 
you get to like the the scale 

725
00:45:10,520 --> 00:45:16,680
that isn't needed for demand. 
So 1, I know one project has 

726
00:45:16,680 --> 00:45:19,280
gotten a little bit of 
attention. 

727
00:45:19,280 --> 00:45:22,200
I think still, still very, very 
early, it's 00. 

728
00:45:22,600 --> 00:45:24,840
So where they're trying to 
create this, you know, private 

729
00:45:24,840 --> 00:45:29,320
fiber network, do you think 
that's going to be needed? 

730
00:45:30,040 --> 00:45:31,760
Yeah, it's not, it's not really 
fiber. 

731
00:45:31,760 --> 00:45:35,760
And this is maybe I can explain 
to folks why how it works and 

732
00:45:35,760 --> 00:45:40,600
why it's not scary. 
Basically there's there's 

733
00:45:40,600 --> 00:45:42,240
nothing you need to change about
fiber. 

734
00:45:42,400 --> 00:45:45,840
The cables are all basically the
same for like the last, you 

735
00:45:45,840 --> 00:45:49,560
know, 30 years and light is very
fast. 

736
00:45:49,560 --> 00:45:52,440
What, what the differences are 
is the signal processing in each

737
00:45:52,440 --> 00:45:55,080
hand. 
The switches that like handle 

738
00:45:55,080 --> 00:46:00,400
the, that load the way they're 
designed for throughput is with 

739
00:46:00,400 --> 00:46:05,800
big buffers and those buffers 
increase latency and finance and

740
00:46:06,040 --> 00:46:10,160
US right, like effectively part 
of the, the finance world, we 

741
00:46:10,160 --> 00:46:12,000
want to have the lowest latency 
possible. 

742
00:46:12,360 --> 00:46:14,560
So what we need is different 
kinds of switches. 

743
00:46:15,960 --> 00:46:19,280
So every data center in the 
world, you can just go and tell 

744
00:46:19,280 --> 00:46:23,560
them, hey, give me this switch, 
I want a super low latency 

745
00:46:23,560 --> 00:46:26,440
switch. 
I want this dedicated lane and 

746
00:46:26,440 --> 00:46:29,560
somebody has to go do that work 
to go do those deals, talk to 

747
00:46:29,560 --> 00:46:33,360
the people and stuff. 
And but in and of itself, it can

748
00:46:33,360 --> 00:46:35,920
be very decentralized. 
All these switches are in 

749
00:46:35,920 --> 00:46:38,720
different parts of the world and
different data centers under 

750
00:46:38,720 --> 00:46:40,960
different ISPs. 
They can all be owned by 

751
00:46:40,960 --> 00:46:43,640
different providers or whatever.
So that part could actually be 

752
00:46:43,640 --> 00:46:47,040
very decentralized. 
The fiber, no one's going to 

753
00:46:47,040 --> 00:46:48,400
change that. 
It's already laid. 

754
00:46:49,400 --> 00:46:56,880
So a, a bunch of the stuff is 
very much like in spirit of the 

755
00:46:56,880 --> 00:47:01,240
Internet and and crypto, I 
think, but it is one protocol. 

756
00:47:01,280 --> 00:47:06,560
And the goal is to use 00 as an 
overlay just to have a, if the 

757
00:47:06,560 --> 00:47:10,600
network is running in the fast 
happy path that all the messages

758
00:47:10,600 --> 00:47:13,880
like when we need to send out 
votes that can all go through 

759
00:47:13,880 --> 00:47:16,600
the multicast super fast path 
for 00. 

760
00:47:16,880 --> 00:47:20,280
If that fails, they're still 
going to arrive over the 

761
00:47:20,280 --> 00:47:24,160
Internet, you know, 4500 
milliseconds later. 

762
00:47:24,800 --> 00:47:28,400
But what we want is for the 
happy path when everything is 

763
00:47:28,400 --> 00:47:30,600
working, for things to be as 
fast as possible. 

764
00:47:33,800 --> 00:47:38,320
Cool. 
On the topic of then security, 

765
00:47:38,920 --> 00:47:42,840
so on Ethereum over the many 
years there have been, yeah, 

766
00:47:42,880 --> 00:47:49,440
kind of a number of of huge 
hacks and yeah, ways where 

767
00:47:49,440 --> 00:47:52,600
people lost money. 
How so far has this been on 

768
00:47:52,600 --> 00:47:54,440
Solana? 
What has been the biggest 

769
00:47:54,440 --> 00:47:57,840
security incidents? 
I think wormhole was the biggest

770
00:47:57,840 --> 00:48:03,480
one and that was really 
unfortunate bug there was. 

771
00:48:03,720 --> 00:48:05,640
This bug didn't exist in World 
War One. 

772
00:48:06,160 --> 00:48:11,400
And then in the second version 
they introduced this bug where 

773
00:48:11,400 --> 00:48:16,520
you could fake the proof that 
there was a mint on the other 

774
00:48:16,520 --> 00:48:22,560
side and an attacker exploited 
it right when they posted the 

775
00:48:22,560 --> 00:48:24,800
fix for it in their public 
GitHub. 

776
00:48:25,360 --> 00:48:28,160
So the attacker was watching 
their GitHub and waiting for the

777
00:48:28,160 --> 00:48:31,360
balances and wormhole to 
increase up to the mat. 

778
00:48:31,400 --> 00:48:35,560
You know, as as much as they 
could before they did the bug. 

779
00:48:35,560 --> 00:48:37,680
So this is like a professional 
attacker. 

780
00:48:37,680 --> 00:48:41,240
I don't remember for sure, but 
it might have been Lazarus Group

781
00:48:42,520 --> 00:48:46,120
that sucks like this. 
This, this stuff sucks. 

782
00:48:48,120 --> 00:48:52,680
It's hard to really fix. 
There's formal verification 

783
00:48:52,680 --> 00:48:55,800
companies that I think similar. 
Similar approach to how they 

784
00:48:55,800 --> 00:48:59,840
formally verify stuff in 
Ethereum is typically you 

785
00:49:00,760 --> 00:49:04,760
recompile the code through LLVM 
and you can use the intermediate

786
00:49:04,760 --> 00:49:07,000
output and run. 
There's formal provers that can 

787
00:49:07,000 --> 00:49:13,200
run on top about to to test some
properties I have thought of 

788
00:49:14,640 --> 00:49:18,880
like adding like the. 
The nice thing about Solana is 

789
00:49:18,880 --> 00:49:20,760
the code is separated from 
state. 

790
00:49:21,160 --> 00:49:26,120
So you could actually load, in 
theory, separate programs that 

791
00:49:26,120 --> 00:49:29,120
implement the exact same state 
transition function, run them 

792
00:49:29,120 --> 00:49:32,160
both and then see if they 
disagree and then abort. 

793
00:49:34,000 --> 00:49:36,080
Do we need that level of 
redundancy? 

794
00:49:36,080 --> 00:49:38,840
So we have redundant 
implementations for smart 

795
00:49:38,840 --> 00:49:41,080
contracts too. 
And obviously the user will need

796
00:49:41,080 --> 00:49:42,920
to pay for twice as much compute
and stuff. 

797
00:49:42,920 --> 00:49:46,480
But like compute is one of the 
easiest, much easier to scale 

798
00:49:46,480 --> 00:49:49,360
than bandwidth. 
So like to me that that's almost

799
00:49:49,360 --> 00:49:50,760
like a no brainer if it would 
help. 

800
00:49:52,680 --> 00:49:55,600
So that that's scary. 
I, I don't think Solana is any 

801
00:49:55,600 --> 00:49:59,240
safer than Ethereum for new 
code. 

802
00:50:00,120 --> 00:50:06,760
One advantage that that's kind 
of weird is that because of some

803
00:50:06,760 --> 00:50:11,560
idiosynchronicies of SVM, people
don't really write interfaces 

804
00:50:11,560 --> 00:50:14,640
for smart contracts. 
So there's no ERC 20 interface. 

805
00:50:15,160 --> 00:50:19,600
There's an implementation of the
token program, and everybody 

806
00:50:19,600 --> 00:50:23,400
uses that program. 
So it's like as if you had one 

807
00:50:23,400 --> 00:50:27,440
canonical ERC 20. 
So that means that if you're a 

808
00:50:27,680 --> 00:50:32,680
default protocol and you only 
accept SPL tokens, there's no 

809
00:50:33,680 --> 00:50:37,200
way for the attacker to make to 
create a bad implementation of 

810
00:50:37,200 --> 00:50:40,720
your C20 and steal funds from 
your users. 

811
00:50:41,120 --> 00:50:45,160
So that has reduced a bunch of 
the kind of attacks that you see

812
00:50:45,160 --> 00:50:49,560
sometimes with like pool 
exploits or like bugs in the the

813
00:50:49,560 --> 00:50:54,280
RC 20s are legitimately like 
people making bad ERC 20s to 

814
00:50:54,280 --> 00:50:58,720
track to to trick users. 
And that has reduced I think a 

815
00:50:58,720 --> 00:51:04,000
lot of the composability 
friction because then like you 

816
00:51:04,000 --> 00:51:06,680
can build a company that doesn't
write any smart contracts at 

817
00:51:06,680 --> 00:51:09,600
all. 
You simply just reuse all these 

818
00:51:09,600 --> 00:51:12,560
already pre built Lego pieces 
and they're all composable 

819
00:51:12,560 --> 00:51:15,040
because everyone accepts the 
exact same implementations. 

820
00:51:15,840 --> 00:51:17,200
And that's been interesting to 
see. 

821
00:51:17,200 --> 00:51:21,440
So I don't know if Pomp wrote 
their own bonding curve. 

822
00:51:21,440 --> 00:51:24,360
They might have, but they didn't
build the AMM, they didn't write

823
00:51:24,360 --> 00:51:27,360
the the token contract. 
All those have been standard. 

824
00:51:27,880 --> 00:51:31,960
Like I think they use the Radium
AMM so that that's kind of like 

825
00:51:31,960 --> 00:51:35,560
one of the examples about. 
Yeah. 

826
00:51:35,560 --> 00:51:38,360
In Ethereum, I think we had seen
first this class of our kind of 

827
00:51:38,360 --> 00:51:40,040
bunch of, well, smart contract 
hacks. 

828
00:51:40,320 --> 00:51:43,840
But very recently there was, 
yeah, kind of a new very, very 

829
00:51:43,840 --> 00:51:48,520
large hack that was not related 
to smart contracts directly, but

830
00:51:48,520 --> 00:51:52,960
rather to, yeah, interfaces 
being compromised. 

831
00:51:53,360 --> 00:51:56,800
And because, I mean, the reality
is if you interact with a 

832
00:51:56,800 --> 00:52:03,360
somewhat more complex program, 
then yeah, go to some interface,

833
00:52:03,440 --> 00:52:07,760
it essentially triggers a 
transaction that kind of on the 

834
00:52:07,760 --> 00:52:09,960
interface promises you, you to 
do something. 

835
00:52:10,280 --> 00:52:13,880
But of course, unfortunately, if
the website is the interface is 

836
00:52:13,880 --> 00:52:20,040
hacked in some form, it is 
absolutely or at least in 

837
00:52:20,040 --> 00:52:21,840
Ethereum. 
And I kind of would be curious. 

838
00:52:21,840 --> 00:52:25,040
About talking about buy bit. 
For example, yeah. 

839
00:52:25,080 --> 00:52:28,520
Or I mean, for sure, yeah, so. 
It was actually UI interface, 

840
00:52:28,560 --> 00:52:30,040
right? 
The user interface, not the 

841
00:52:30,240 --> 00:52:31,920
programmatic interface of the. 
Yeah, yeah. 

842
00:52:31,920 --> 00:52:34,360
It's the user interface. 
User interface shows you you're 

843
00:52:34,360 --> 00:52:37,840
doing transaction A, but to the 
wallet it's sending some 

844
00:52:37,840 --> 00:52:41,200
malicious payload. 
And the question is now do you 

845
00:52:41,200 --> 00:52:46,960
have any chance to understand in
the wallet what, what the state 

846
00:52:46,960 --> 00:52:49,600
change of the transaction will 
be? 

847
00:52:49,600 --> 00:52:53,120
And yeah, kind of is. 
Is there a realistic chance to? 

848
00:52:55,680 --> 00:52:59,800
I don't actually think that 
this, I imagine this should be 

849
00:52:59,800 --> 00:53:04,200
possible to do on Ethereum, but 
maybe easier on Solana. 

850
00:53:04,840 --> 00:53:08,000
Is that like, because you know 
which accounts are token 

851
00:53:08,000 --> 00:53:12,680
accounts and the implementation 
of those tokens, they're all the

852
00:53:12,680 --> 00:53:15,280
same. 
What I've been recommending 

853
00:53:15,280 --> 00:53:18,640
people and there's a project 
called Lighthouse Protocol is 

854
00:53:18,640 --> 00:53:24,160
they add guard instruction that 
aborts if the resulting state at

855
00:53:24,160 --> 00:53:26,840
the end of the transaction is 
different than the user expects.

856
00:53:27,320 --> 00:53:31,960
So this would also protect you 
from like the you write a do you

857
00:53:31,960 --> 00:53:34,080
write a transaction? 
Do you think you're hitting an 

858
00:53:34,080 --> 00:53:38,280
AMM attacker does a program 
upgrade that just steals your 

859
00:53:38,640 --> 00:53:41,680
your coins, right? 
So they fake the simulation like

860
00:53:41,680 --> 00:53:43,480
this is kind of like a classic 
attack. 

861
00:53:43,480 --> 00:53:46,000
You simulate your transaction 
looks fine, you submit it, but 

862
00:53:46,000 --> 00:53:48,680
then something, something 
changes in the in the chain 

863
00:53:48,920 --> 00:53:51,440
attacker sets a bit right? 
And it does something different.

864
00:53:51,800 --> 00:53:55,240
So to protect against that, you 
can add that guard transaction 

865
00:53:55,680 --> 00:54:01,800
and then your like your cold 
storage system should have 

866
00:54:01,960 --> 00:54:06,400
effectively rules and policies 
in the cold implemented in the 

867
00:54:06,400 --> 00:54:09,800
cold storage. 
Not relying on the human to go 

868
00:54:09,800 --> 00:54:13,120
look at the trusted display and 
parse that string that actually 

869
00:54:13,120 --> 00:54:15,680
checks for that guard 
transaction and checks that the 

870
00:54:15,680 --> 00:54:19,160
spending limits and all the 
policies that you want are not 

871
00:54:19,160 --> 00:54:22,120
exceeded. 
This is what I have been like 

872
00:54:22,120 --> 00:54:24,640
pushing people to do. 
And if you can kind of get 

873
00:54:24,640 --> 00:54:26,800
there, I think with Keystone 
Wallet, they have a developer 

874
00:54:26,800 --> 00:54:29,720
API where you can 
programmatically sets and rules 

875
00:54:29,720 --> 00:54:34,200
sets and stuff. 
But yeah, this is I, I think 

876
00:54:34,600 --> 00:54:39,840
this particular UI hack issues 
are solvable through kind of 

877
00:54:39,840 --> 00:54:44,160
more robust security policies 
around cold signing and stuff. 

878
00:54:46,000 --> 00:54:48,520
I don't know if simulation is 
much more complicated than 

879
00:54:48,520 --> 00:54:54,960
Ethereum, but if you know this 
is a cold storage system, you 

880
00:54:54,960 --> 00:54:57,240
know that it should only be 
doing simple transfers. 

881
00:54:57,240 --> 00:54:59,240
You know the accounts passed to 
it should only be token 

882
00:54:59,240 --> 00:55:01,160
accounts. 
You can then add guard 

883
00:55:01,160 --> 00:55:04,360
transactions that assert all 
that and restrict the balances. 

884
00:55:04,640 --> 00:55:06,720
And then when you hit the chain,
it'll abort. 

885
00:55:07,000 --> 00:55:10,000
Attacker did something or 
screwed up the thing aborts, 

886
00:55:10,000 --> 00:55:13,760
pager duty goes off. 
Everyone figures out that's like

887
00:55:13,760 --> 00:55:17,480
what happened, right? 
I think that that is solvable 

888
00:55:17,480 --> 00:55:20,560
with technology. 
I think stuff that's really 

889
00:55:20,560 --> 00:55:26,480
hard, I think it's just smart 
contracts in general because the

890
00:55:27,160 --> 00:55:33,520
the more interesting ones are 
like risk systems like Ave. or 

891
00:55:33,520 --> 00:55:36,200
Perps or any of these systems 
that are not just purely 

892
00:55:36,200 --> 00:55:39,200
trading, they're managing risk. 
They have a lot of inputs like 

893
00:55:39,200 --> 00:55:45,120
oracles and the attack vectors 
there are not obvious, right? 

894
00:55:45,120 --> 00:55:50,440
You have like there's latency 
games and exit games between the

895
00:55:50,440 --> 00:55:52,960
liquidity bots and the capital 
and the contracts. 

896
00:55:52,960 --> 00:55:56,760
Those are those are very, very 
hard to get right and proving 

897
00:55:56,760 --> 00:56:02,160
systems can't help there. 
But I, I think that these kind 

898
00:56:02,160 --> 00:56:05,920
of high level smart contracts 
that manage risk, if they can 

899
00:56:05,920 --> 00:56:09,520
scale, they're probably the most
destructive part to traditional 

900
00:56:09,520 --> 00:56:13,440
finance because this is the 
entire function of any bank or 

901
00:56:13,440 --> 00:56:16,280
any, any fund or anything is 
managing risk. 

902
00:56:16,280 --> 00:56:21,040
If you can automate it, you've 
and you can scale it up, I think

903
00:56:21,120 --> 00:56:23,720
that's very, very disruptive and
and very valuable. 

904
00:56:25,240 --> 00:56:29,440
So with regards to smart 
contract security, I think today

905
00:56:29,440 --> 00:56:34,920
in Solana a lot of smart 
contracts are upgradable and 

906
00:56:34,920 --> 00:56:37,680
it's also pretty common for 
smart contracts to be closed 

907
00:56:37,680 --> 00:56:39,800
source. 
What do you? 

908
00:56:39,800 --> 00:56:42,200
Follow those, just don't use 
them. 

909
00:56:44,200 --> 00:56:49,400
Still do it. 
You have the power as a user to 

910
00:56:49,400 --> 00:56:53,400
not use those. 
But if you do have to use them, 

911
00:56:54,400 --> 00:56:57,960
there's a difference between 
being an LP into a closed source

912
00:56:57,960 --> 00:57:00,120
smart contract versus trading in
it. 

913
00:57:00,320 --> 00:57:03,160
If you're trading in it, then 
use Lite protocol which will 

914
00:57:03,160 --> 00:57:06,200
guard your transaction. 
If that closed source contract 

915
00:57:06,200 --> 00:57:09,960
does something wacky, whereas 
there's or there's an upgrade 

916
00:57:09,960 --> 00:57:12,280
that happens in the middle of 
your transaction, you can 

917
00:57:12,280 --> 00:57:13,920
actually protect yourself 
against that. 

918
00:57:14,240 --> 00:57:18,280
If you're an LP, you are moving 
your funds into that thing and 

919
00:57:18,280 --> 00:57:19,880
you're letting in custody your 
funds. 

920
00:57:19,880 --> 00:57:22,600
You should know what who the 
hell you're giving your funds 

921
00:57:22,600 --> 00:57:24,320
to. 
Don't do that. 

922
00:57:26,280 --> 00:57:29,440
Look for open source contracts, 
look for formally verified smart

923
00:57:29,440 --> 00:57:33,240
contracts. 
Look for like multi sigs with 

924
00:57:33,240 --> 00:57:35,200
time locks. 
If they have to have a multi sig

925
00:57:35,200 --> 00:57:38,600
for upgrade to make sure there's
time locks on on those things. 

926
00:57:38,600 --> 00:57:41,600
Like, there's a whole bunch of 
things you can do to defend 

927
00:57:41,600 --> 00:57:46,960
yourself, and you should ask the
companies that provide these 

928
00:57:46,960 --> 00:57:49,440
services to go do that and 
advertise what they are. 

929
00:57:50,440 --> 00:57:54,440
But yeah, like, I think that 
part sucks. 

930
00:57:54,440 --> 00:57:58,680
And the part of it is I think 
developers being lazy or 

931
00:57:58,960 --> 00:58:02,280
probably not lazy. 
They're just, you know, limited 

932
00:58:02,280 --> 00:58:04,640
runway, limited time trying to 
get traction. 

933
00:58:05,120 --> 00:58:08,080
But I think as protocols mature 
like I think you really need to 

934
00:58:08,080 --> 00:58:12,440
demand for them to kind of put 
in the work to to level up their

935
00:58:12,560 --> 00:58:16,480
OPSEC and the security that and 
the rest they expose their users

936
00:58:16,480 --> 00:58:19,360
to do. 
You think there's anything that 

937
00:58:19,360 --> 00:58:24,880
can be done, I don't know from 
your side or the OR you know 

938
00:58:24,880 --> 00:58:28,160
like what can be done to try to 
accelerate this and try to get 

939
00:58:28,160 --> 00:58:34,040
more open source immutable 
contracts or is it just a user 

940
00:58:34,040 --> 00:58:39,040
demand type thing that you know,
it's hopefully comes with time 

941
00:58:39,280 --> 00:58:43,600
maturity. 
It'd be good if there were like 

942
00:58:43,760 --> 00:58:49,200
groups in the ecosystem that 
could kind of make a list of all

943
00:58:49,200 --> 00:58:53,480
the all the best practices who's
following them. 

944
00:58:54,360 --> 00:58:58,560
Neodime tried this with like 
security dot TXT and the and the

945
00:58:58,760 --> 00:59:03,840
and the GitHub and that that had
some some limited positive 

946
00:59:03,840 --> 00:59:06,640
impact. 
Yeah, it's probably should be 

947
00:59:06,640 --> 00:59:10,240
like a group ecosystem effort. 
It's hard to maintain those 

948
00:59:10,240 --> 00:59:13,040
systems and and like keep them 
up to date. 

949
00:59:14,840 --> 00:59:17,400
So it needs, I think, like input
from a lot of folks. 

950
00:59:19,440 --> 00:59:24,920
So we we talked about economics 
a little bit before, but you 

951
00:59:24,920 --> 00:59:28,120
know, right now I feel like 
we've seen actually the most 

952
00:59:28,120 --> 00:59:33,000
vibrant sort of governance 
discussion that at least I'm 

953
00:59:33,000 --> 00:59:38,320
aware of in Solana with this 
SIMT 228, right? 

954
00:59:38,320 --> 00:59:44,160
That multi coin proposed change 
to the inflation, which would 

955
00:59:44,160 --> 00:59:47,600
make it dependent on how much is
being staked. 

956
00:59:47,880 --> 00:59:50,360
Because I think right now, 
right, we've had this inflation 

957
00:59:50,360 --> 00:59:53,360
that kind of gradually, slowly 
goes down with time. 

958
00:59:54,640 --> 00:59:58,240
What are your thoughts first of 
all on on this specific 

959
00:59:58,240 --> 01:00:00,640
proposal? 
Yeah. 

960
01:00:00,640 --> 01:00:08,160
So I think the perfect way to 
have inflation is that like the 

961
01:00:08,160 --> 01:00:12,000
network needs to get some 
stakers to run boxes and pay for

962
01:00:12,000 --> 01:00:15,600
the boxes running. 
And the only thing that the 

963
01:00:15,600 --> 01:00:17,560
network can really sell is more 
tokens. 

964
01:00:17,920 --> 01:00:19,760
So this is what the inflation 
piece. 

965
01:00:20,200 --> 01:00:25,320
So if you were to run an 
auction, you can take the top 

966
01:00:25,400 --> 01:00:29,680
best bids that are sufficient 
for you to to run a secure 

967
01:00:29,680 --> 01:00:31,280
network. 
And you don't know what those 

968
01:00:31,280 --> 01:00:34,040
are, you kind of guess what that
number is. 

969
01:00:34,360 --> 01:00:37,080
But effectively you can kind of 
run this algorithm. 

970
01:00:37,440 --> 01:00:44,640
You start with 50%, you take the
top best 50% bids to stake and 

971
01:00:44,640 --> 01:00:48,000
only those and you offer 
everybody the same price to run 

972
01:00:48,000 --> 01:00:52,160
like a Dutch auction. 
And if that price is below 0, 

973
01:00:52,160 --> 01:00:54,680
because people can bid a 
negative interest rate that 

974
01:00:54,680 --> 01:00:57,200
they're willing to burn some of 
their tokens for the right to 

975
01:00:57,200 --> 01:01:02,680
make blocks, you then increase 
the amount of stake that you 

976
01:01:02,680 --> 01:01:04,720
want. 
So you're targeting zero. 

977
01:01:05,080 --> 01:01:09,280
And if the bid is above 0, then 
you decrease within some limits 

978
01:01:09,280 --> 01:01:11,760
that at a high level people 
think are safe. 

979
01:01:12,160 --> 01:01:16,560
We've seen Ethereum run at like 
20 to 30% stake without any 

980
01:01:16,560 --> 01:01:18,440
problems at all, like in the 
security side. 

981
01:01:18,440 --> 01:01:23,440
So I think having the lowest 
limit of 20 would be reasonable.

982
01:01:23,720 --> 01:01:29,000
And I don't, I don't see any 
marginal benefit above like 80%.

983
01:01:29,000 --> 01:01:32,600
So between 20 and 80%, right. 
This thing is bouncing around 

984
01:01:32,840 --> 01:01:36,440
and people are bidding those 
bids have actually create a 

985
01:01:36,440 --> 01:01:40,840
curve that looks very similar to
the curve proposed in 228. 

986
01:01:41,080 --> 01:01:43,760
Now there's an error there 
because the curve in 228 is 

987
01:01:43,760 --> 01:01:46,360
fixed. 
There is this curve that you 

988
01:01:46,360 --> 01:01:49,200
know, Max and a bunch of other 
smart people thought would be 

989
01:01:49,200 --> 01:01:53,920
the best approximation. 
But that error between the 

990
01:01:54,080 --> 01:01:58,640
market rate in all these dynamic
environments and the proposed 

991
01:01:58,640 --> 01:02:02,600
curve is going to show up as the
network over paying for steak. 

992
01:02:02,640 --> 01:02:04,600
It's much, much smaller than the
current setup. 

993
01:02:05,440 --> 01:02:09,080
So my view is that like running 
these auctions and the 

994
01:02:09,080 --> 01:02:12,440
complexity of telling users, oh,
you need to pick a price and 

995
01:02:12,440 --> 01:02:15,200
maybe you need to pick a 
negative price because there's a

996
01:02:15,200 --> 01:02:18,600
lot of block rewards. 
It's just so complicated that 

997
01:02:18,600 --> 01:02:21,520
there's no way to really scale 
it up outside of like a few 

998
01:02:21,520 --> 01:02:24,120
small professionals. 
And it's a pain in the ass to 

999
01:02:24,120 --> 01:02:26,880
run. 
Imagine you as a validator that 

1000
01:02:26,880 --> 01:02:30,920
your stakers constantly have to 
bid, like every epoch no matter 

1001
01:02:30,920 --> 01:02:32,840
how long it is right, Every 10. 
Months you could be the 

1002
01:02:32,840 --> 01:02:38,040
validator was bidding. 
Sure, could be the validator's 

1003
01:02:38,040 --> 01:02:41,160
bidding, but it's still like a 
pain and pain to run and manage 

1004
01:02:41,160 --> 01:02:44,960
that. 
I think my view is like, don't 

1005
01:02:45,080 --> 01:02:46,960
let the perfect be the enemy of 
the good. 

1006
01:02:47,240 --> 01:02:49,400
This curve is a the proposed 
curve is a pretty good 

1007
01:02:49,400 --> 01:02:53,680
approximation of that process, 
and it's much, much simpler to 

1008
01:02:53,680 --> 01:02:55,680
implement. 
There's no auction. 

1009
01:02:55,680 --> 01:02:58,960
There's no like auctions 
themselves have a whole bunch of

1010
01:02:58,960 --> 01:03:03,280
complexity that's gnarly and 
running them is gnarly. 

1011
01:03:03,640 --> 01:03:07,520
So in general, I'm I'm very 
supportive to 228. 

1012
01:03:07,840 --> 01:03:11,800
What I want to emphasize is that
like Solana has never been a 

1013
01:03:11,800 --> 01:03:15,840
money like the the point of soul
is to disincentivize spam. 

1014
01:03:16,400 --> 01:03:22,520
If that we have another 97% 
negative downturn in the market 

1015
01:03:22,720 --> 01:03:25,920
and it's the bottom of the bear 
and this curve is not working 

1016
01:03:25,920 --> 01:03:31,080
out, people will change it. 
That's OK like that, right? 

1017
01:03:31,080 --> 01:03:33,360
I think people need to 
understand that there isn't like

1018
01:03:33,360 --> 01:03:39,640
this Bitcoin ask we, we don't 
care about our grandfather. 

1019
01:03:41,720 --> 01:03:44,320
The sense of our grandfather 
don't bother us. 

1020
01:03:44,320 --> 01:03:46,480
Like it doesn't matter what 
Bitcoin did in their monetary 

1021
01:03:46,480 --> 01:03:48,560
policy. 
Solana can do a whole bunch of 

1022
01:03:48,560 --> 01:03:52,120
stuff that I think Ethereum is 
still stuck on in this trying to

1023
01:03:52,120 --> 01:03:55,920
be money and and like compete 
with Bitcoin that the Solana 

1024
01:03:55,920 --> 01:03:59,280
ecosystem is not. 
So I think this curve is an 

1025
01:03:59,280 --> 01:04:03,400
improvement and I'm supportive 
and I'm, I'm encouraging people 

1026
01:04:03,400 --> 01:04:06,840
to vote for it and I think it'll
reduce emissions And emissions 

1027
01:04:06,840 --> 01:04:11,960
are in a perfect world, 
emissions don't matter because 

1028
01:04:11,960 --> 01:04:15,200
the, there is no taxes and 
there's no middle men that can 

1029
01:04:15,200 --> 01:04:18,760
take a cut. 
But in the reality, you know, 

1030
01:04:18,760 --> 01:04:23,520
like you look at fees from 
custodians and centralized 

1031
01:04:23,520 --> 01:04:27,080
exchanges on the rewards, it's 
just like a huge subsidy. 

1032
01:04:27,080 --> 01:04:30,640
And that's not even counting the
the average global tax rate on 

1033
01:04:30,880 --> 01:04:35,840
on those earnings. 
Maybe, maybe on this note, would

1034
01:04:35,840 --> 01:04:39,320
would you agree with with with 
the statement to say emissions 

1035
01:04:39,320 --> 01:04:42,520
are a tax on on everyone who's 
not staking? 

1036
01:04:43,480 --> 01:04:46,600
Oh yeah, the the emissions 
themselves, it's just money 

1037
01:04:46,600 --> 01:04:50,560
moving around the black box. 
But it's not like the group of 

1038
01:04:50,560 --> 01:04:54,200
users that are staking and not 
staking are different people. 

1039
01:04:54,400 --> 01:04:56,760
You can literally be both at the
same. 

1040
01:04:56,760 --> 01:05:00,960
Time, right. 
Well, yeah, certainly in in 

1041
01:05:00,960 --> 01:05:03,400
Ethereum there are some people 
that that have a strong feeling 

1042
01:05:03,400 --> 01:05:07,080
there should be reasons for ESA 
to not be staked and just be 

1043
01:05:07,080 --> 01:05:11,600
held in ESA and they see kind of
staked ESA potentially as a 

1044
01:05:11,600 --> 01:05:15,280
threat to the whatever money 
Ness of those. 

1045
01:05:15,280 --> 01:05:18,120
So things again you don't really
care about or yeah. 

1046
01:05:18,600 --> 01:05:25,800
So would, would would you say 90
or even close to 100% Solana 

1047
01:05:25,800 --> 01:05:30,000
staked or or be be in the form 
of some stake Solana or 

1048
01:05:30,000 --> 01:05:33,040
something like that took a nice 
stake Solana that you wouldn't 

1049
01:05:33,040 --> 01:05:37,680
see as an issue? 
If there's like UX issues around

1050
01:05:37,680 --> 01:05:40,320
it like that's what I would care
more I think. 

1051
01:05:41,440 --> 01:05:44,600
I I don't like when things hit 
the limit like it it seems like 

1052
01:05:44,600 --> 01:05:48,520
there's a bug somewhere 
incentives wise like it did. 

1053
01:05:48,520 --> 01:05:51,440
You don't need 100% stakes. 
Sure, yeah. 

1054
01:05:52,120 --> 01:05:56,400
Yeah, you don't need it, but but
the question is, wouldn't it be 

1055
01:05:56,400 --> 01:06:00,600
rational or if, if if staked 
kind of a tokenized stake 

1056
01:06:00,600 --> 01:06:05,400
version is just so easy to 
access, then why not get the 

1057
01:06:05,400 --> 01:06:07,680
addition of the 1% essentially 
or whatever it is? 

1058
01:06:08,480 --> 01:06:12,560
Well then why isn't the rate 
negative would be my question? 

1059
01:06:14,320 --> 01:06:18,840
Like if it's at 100% then people
should be then somebody's 

1060
01:06:18,840 --> 01:06:22,720
overpaying, right? 
So to me it bugs my market like 

1061
01:06:22,720 --> 01:06:26,360
free market thing more than like
whether it's usable as money or 

1062
01:06:26,360 --> 01:06:28,880
not. 
It's like it seems like the 

1063
01:06:28,920 --> 01:06:32,920
whatever curve you picked, it 
has a bug in it and has caused 

1064
01:06:32,920 --> 01:06:35,280
the IT to hit the limit point, 
right? 

1065
01:06:35,600 --> 01:06:36,800
So that's what you want to 
avoid. 

1066
01:06:36,800 --> 01:06:39,320
You want the parameters to be 
set somewhere where you're not 

1067
01:06:39,320 --> 01:06:43,200
at 0 or 100%. 
But like, if in general, like I 

1068
01:06:43,200 --> 01:06:45,520
don't, I don't think there's any
threat to the muddiness of it. 

1069
01:06:45,520 --> 01:06:49,880
And I don't really care if Seoul
is used as money. 

1070
01:06:50,800 --> 01:06:55,040
If, you know, if there's ten 
billion per day volume of ETH 

1071
01:06:55,240 --> 01:06:59,080
versus everything else on 
Solana, it's great we hit PMF. 

1072
01:06:59,600 --> 01:07:01,880
There's real activity. 
Like why? 

1073
01:07:01,880 --> 01:07:06,320
Why would anyone be upset? 
Shade, Maury, I don't care. 

1074
01:07:08,320 --> 01:07:11,680
Cool. 
I think you started, you started

1075
01:07:11,680 --> 01:07:18,480
with with saying that, yeah, 
some things came as expected. 

1076
01:07:18,480 --> 01:07:21,880
Other things specifically the 
use cases did not came as 

1077
01:07:21,880 --> 01:07:25,760
expected. 
So maybe making an outlook for 

1078
01:07:25,880 --> 01:07:31,080
yeah the next couple of years, 
do you, do you think that those 

1079
01:07:31,880 --> 01:07:34,960
finance use cases that you 
initially expected or what are 

1080
01:07:34,960 --> 01:07:39,320
the blockers there and how how 
do you see that or are too 

1081
01:07:39,320 --> 01:07:42,600
difficult to guess? 
These unexpected use cases 

1082
01:07:42,600 --> 01:07:45,960
surfaced a lot of problems that 
I think are real. 

1083
01:07:47,800 --> 01:07:52,720
I think there's like I, I think 
we need multiple concurrent 

1084
01:07:52,720 --> 01:07:57,080
leaders and like the, the 
ability for applications to 

1085
01:07:57,680 --> 01:08:01,600
prioritize market maker cancels 
before takers, like all that 

1086
01:08:01,600 --> 01:08:06,600
stuff that needs to be 
implemented before Tradfi really

1087
01:08:06,600 --> 01:08:11,840
takes the system seriously. 
Because the like not even like 

1088
01:08:11,840 --> 01:08:14,640
the the launches themselves. 
Like I think are like Abd 

1089
01:08:14,640 --> 01:08:16,279
problem. 
Like you've seen a lot of like 

1090
01:08:16,279 --> 01:08:20,080
really extractive launches 
launched by like terrible people

1091
01:08:20,080 --> 01:08:21,479
that should all be nude from 
orbit. 

1092
01:08:21,880 --> 01:08:24,680
Like that stuff I feel like is 
is like business development. 

1093
01:08:24,680 --> 01:08:26,840
You just need more robust 
platforms that have better 

1094
01:08:26,840 --> 01:08:30,680
enforcement and stuff like that.
But on the network layer itself,

1095
01:08:30,680 --> 01:08:34,040
there's a whole bunch of 
microstructure problems with the

1096
01:08:34,040 --> 01:08:39,399
way that transaction land and 
how MEV works that I think need 

1097
01:08:39,399 --> 01:08:45,319
to be fixed and addressed for me
to feel comfortable with like 

1098
01:08:45,319 --> 01:08:48,960
people's 401 KS running in these
things like that. 

1099
01:08:48,960 --> 01:08:53,479
That's like, I think with meme 
coins and NFTS, it's like the 

1100
01:08:53,479 --> 01:08:55,800
stakes are medium. 
Like the volumes are real and 

1101
01:08:55,800 --> 01:08:58,080
the numbers are real, and 
there's real, real money at 

1102
01:08:58,080 --> 01:09:00,560
stake and people really need to 
take it seriously. 

1103
01:09:00,560 --> 01:09:05,680
But we're not yet like, dealing 
with like people's savings, 

1104
01:09:05,680 --> 01:09:08,600
right? 
And I want the network to be so 

1105
01:09:08,600 --> 01:09:12,840
robust that I can tell, like you
should, you know, don't trade on

1106
01:09:12,840 --> 01:09:15,479
NASDAQ, trade on Solana. 
Like it's going to be better 

1107
01:09:15,479 --> 01:09:17,279
pricing for people. 
It's more fair and more 

1108
01:09:17,279 --> 01:09:19,240
transparent that that's the 
ultimate goal. 

1109
01:09:19,560 --> 01:09:25,160
Because but like, there's a 
whole I was more, I was more and

1110
01:09:25,160 --> 01:09:28,399
I, I thought it would take four 
years ago, I would have said 

1111
01:09:28,399 --> 01:09:31,080
we're ready in the year. 
Now I'm like, shit, this is 

1112
01:09:31,080 --> 01:09:36,960
going to take five years to fix.
Just those problems are are so 

1113
01:09:36,960 --> 01:09:41,279
hard. 
Then maybe just one more push 

1114
01:09:41,279 --> 01:09:46,080
back on the on the on the on the
thesis of it needs to be faster 

1115
01:09:46,080 --> 01:09:50,319
and it needs to be. 
I have an alternative thesis 

1116
01:09:50,319 --> 01:09:55,440
that they I think there is 
pretty good literature that 

1117
01:09:55,440 --> 01:10:04,360
shows that at some point, yeah, 
faster, faster systems do not 

1118
01:10:04,720 --> 01:10:08,920
lead to to more efficiency, but 
that there are alternative 

1119
01:10:08,920 --> 01:10:14,440
market structures, namely batch 
auctions or or yeah, micro batch

1120
01:10:14,440 --> 01:10:17,720
auctions. 
And to me that seems like a very

1121
01:10:17,720 --> 01:10:20,400
interesting approach. 
That has been the approach that 

1122
01:10:20,400 --> 01:10:23,040
I have always been pushing for 
blockchain because if you have a

1123
01:10:23,040 --> 01:10:26,680
block, then in a way that is 
kind of you can see it as a 

1124
01:10:26,680 --> 01:10:29,560
batch and you can try to do 
things like single price 

1125
01:10:29,560 --> 01:10:32,520
clearing in this in in, in this 
block. 

1126
01:10:32,520 --> 01:10:36,680
So that is in my view kind of a 
counter grout to this. 

1127
01:10:36,840 --> 01:10:39,200
We just need to be faster to to 
to solve things. 

1128
01:10:40,200 --> 01:10:43,760
I actually agree with you, but I
think my batch auction is 100 

1129
01:10:43,760 --> 01:10:47,720
milliseconds not not fair. 
Not, not, not 12 seconds, Yeah, 

1130
01:10:47,720 --> 01:10:51,960
but I mean, I mean, I think my 
my counterpoint would be how 

1131
01:10:51,960 --> 01:10:56,560
many real world events really 
happen in in in in 12 seconds. 

1132
01:10:56,560 --> 01:11:00,600
So I mean a thesis theoretical 
argument that that if if. 

1133
01:11:01,440 --> 01:11:05,360
Well, to be NASDAQ, I think we 
need like the latency to be 

1134
01:11:05,360 --> 01:11:09,120
basically the round trip around 
the world and for the inclusion 

1135
01:11:09,120 --> 01:11:12,880
latency to be shorter. 
So local block producers that 

1136
01:11:12,880 --> 01:11:16,400
are concurrently within this 120
millisecond auction. 

1137
01:11:16,680 --> 01:11:20,480
I think at that point you can 
reasonably argue that it's as 

1138
01:11:20,480 --> 01:11:23,760
good as price discovery, 
assuming there's no like MEV 

1139
01:11:23,760 --> 01:11:25,280
extraction. 
We solve that. 

1140
01:11:28,320 --> 01:11:30,120
Throw some salt over a knock on 
wood. 

1141
01:11:32,520 --> 01:11:37,080
If we solve those problems, I 
think it's very hard to argue 

1142
01:11:37,080 --> 01:11:40,040
that a faster system is more 
than marginally better. 

1143
01:11:40,320 --> 01:11:45,320
I think at 12 seconds you have 
like this information games that

1144
01:11:45,320 --> 01:11:49,080
are that are still harder to 
solve because you literally can 

1145
01:11:49,080 --> 01:11:52,720
go to NASDAQ, take the trade and
then Arby against the chain and 

1146
01:11:52,720 --> 01:11:55,040
like that that's the opportunity
that I wanna like. 

1147
01:11:55,040 --> 01:11:59,000
Once you eliminate that for the 
most part, then trader that sees

1148
01:11:59,000 --> 01:12:01,840
that newswire and Bloomberg, 
they look at the chain price or 

1149
01:12:01,840 --> 01:12:03,480
NASDAQ price, it's the same 
price. 

1150
01:12:03,840 --> 01:12:06,480
Then it's as good, you know, but
like I I agree with you. 

1151
01:12:06,480 --> 01:12:10,320
You don't need to go to like 
below that latency for a global 

1152
01:12:10,320 --> 01:12:15,120
system because the world's you 
still have like the event that 

1153
01:12:15,120 --> 01:12:17,920
happens in Singapore still has 
to go travel to New York, right?

1154
01:12:17,960 --> 01:12:20,880
So you have still these embedded
latencies that are on the order 

1155
01:12:20,880 --> 01:12:22,880
of, you know, round trip time 
around the world. 

1156
01:12:24,080 --> 01:12:26,360
Yeah. 
And I mean, I think the, with 

1157
01:12:26,360 --> 01:12:30,080
regards to the whole, you know, 
finance coming on chain and 

1158
01:12:30,080 --> 01:12:34,360
stuff, I, I, I, I do think 
there's a huge upside even with 

1159
01:12:34,360 --> 01:12:37,840
all of this, you know, mean coin
defy stuff is that, you know, in

1160
01:12:37,840 --> 01:12:41,680
the end, a lot of the, the 
infrastructure, right, the 

1161
01:12:41,680 --> 01:12:45,440
applications, the ability to 
compose different protocols to 

1162
01:12:45,440 --> 01:12:47,840
collateralize one thing and the 
other. 

1163
01:12:47,840 --> 01:12:52,400
And I think there's just so much
happening there and so much 

1164
01:12:52,400 --> 01:12:55,000
progress there. 
And then I think once you plug 

1165
01:12:55,000 --> 01:12:58,920
in more traditional financial 
assets in there, you'll just 

1166
01:12:58,920 --> 01:13:03,360
have a very powerful system. 
Yeah, on the on the plus side, 

1167
01:13:03,360 --> 01:13:07,520
your if your risk engine 
survives meme coins and crypto, 

1168
01:13:07,520 --> 01:13:12,440
it can deal with like field 
world assets that are much more 

1169
01:13:12,440 --> 01:13:16,640
stable. 
But that's the the hope, at 

1170
01:13:16,640 --> 01:13:20,960
least. 
Is it fair to say for you 

1171
01:13:20,960 --> 01:13:25,080
blockchain means financial 
applications or do you see other

1172
01:13:25,080 --> 01:13:28,760
things? 
It's a good question. 

1173
01:13:28,760 --> 01:13:33,840
I think like I think this, it is
like kind of melted with the 

1174
01:13:33,840 --> 01:13:36,880
Internet. 
Like if you have truly globally,

1175
01:13:36,880 --> 01:13:39,320
global payments with no 
friction, every, everyone can 

1176
01:13:39,320 --> 01:13:41,840
pay every, everywhere. 
That's very different than the 

1177
01:13:41,920 --> 01:13:44,840
the the way the Internet works 
now, because you effectively, 

1178
01:13:45,680 --> 01:13:48,280
because you don't have money on 
the Internet, you have all these

1179
01:13:48,280 --> 01:13:50,840
subscriptions and all this kind 
of friction that created the 

1180
01:13:50,840 --> 01:13:52,640
silos and. 
Around ads. 

1181
01:13:52,840 --> 01:13:55,880
Ads as a business model instead 
of just yeah. 

1182
01:13:56,720 --> 01:14:00,120
So like, and that model silos 
everything, right? 

1183
01:14:00,120 --> 01:14:04,080
YouTube wants its own silo, like
Facebook wants its own silo and 

1184
01:14:04,080 --> 01:14:06,720
they're very, they're fighting 
each other right to for market 

1185
01:14:06,720 --> 01:14:08,960
share. 
You still have some of that, but

1186
01:14:08,960 --> 01:14:13,160
I I feel like just making it 
easy to pay everywhere and 

1187
01:14:13,160 --> 01:14:17,560
everyone could start unraveling 
it in in a more open way. 

1188
01:14:18,680 --> 01:14:21,240
And I like the web. 
I like the idea of like, you 

1189
01:14:21,240 --> 01:14:25,640
know, minimize the cost of 
publishing and like let the free

1190
01:14:25,640 --> 01:14:27,640
world's free market figure it 
out, right? 

1191
01:14:27,640 --> 01:14:30,600
Like I, I think that that's cool
and, and kind of a, a really 

1192
01:14:30,600 --> 01:14:35,800
cool, beautiful thing. 
I think the finance will unlock 

1193
01:14:35,800 --> 01:14:39,640
a lot of other use cases, but 
I'm hoping are are disruptive to

1194
01:14:40,080 --> 01:14:41,920
the big kind of big tech 
monopolies. 

1195
01:14:41,960 --> 01:14:46,280
But we'll see. 
Cool, you want to share anything

1196
01:14:46,280 --> 01:14:48,360
else that's like on your mind at
the moment? 

1197
01:14:49,840 --> 01:14:52,800
It's a lot of mobile's coming 
out soon, so stay tuned. 

1198
01:14:53,600 --> 01:14:55,080
Oh yeah, the. 
The Seeker. 

1199
01:14:55,200 --> 01:14:56,680
The phone. 
Yeah, Seeker. 

1200
01:14:57,800 --> 01:14:59,560
We'll try to disrupt the 
duopoly. 

1201
01:15:00,920 --> 01:15:03,120
What's your hope for the phone 
on like how what? 

1202
01:15:03,120 --> 01:15:04,680
What do you see as the role of 
the phone? 

1203
01:15:06,480 --> 01:15:11,840
So the goal is to get enough 
crypto people in the same 

1204
01:15:11,880 --> 01:15:15,680
ecosystem to where developers 
have like a distribution channel

1205
01:15:16,120 --> 01:15:19,160
and there's like 150,000 
pre-orders. 

1206
01:15:19,600 --> 01:15:23,280
That's a reasonably sized group 
for a crypto app that's actually

1207
01:15:23,360 --> 01:15:26,240
like 50,000 daily active users 
is huge. 

1208
01:15:27,600 --> 01:15:30,520
So if we have the, if we were 
able to capture the right kind 

1209
01:15:30,520 --> 01:15:33,200
of audience and there's a high 
probability that we were because

1210
01:15:33,640 --> 01:15:36,160
people have to pay 500 bucks for
a crypto phone. 

1211
01:15:36,600 --> 01:15:39,280
Those are kind of the users that
you want as a developer in 

1212
01:15:39,320 --> 01:15:41,680
crypto. 
So they have money and they're 

1213
01:15:41,680 --> 01:15:45,200
already crypto native. 
If you can build apps for them 

1214
01:15:45,200 --> 01:15:48,600
that keep their attention and 
they're like super cool, you're 

1215
01:15:48,760 --> 01:15:53,320
saving money on the 20 to 30% 
rake that Apple and Google 

1216
01:15:53,320 --> 01:15:54,800
charge. 
You know, we talk about 

1217
01:15:54,880 --> 01:15:58,040
disrupting finance. 
They charge basis points. 

1218
01:16:01,360 --> 01:16:05,760
Apple and Google charge 
thousands of basis points. 

1219
01:16:05,760 --> 01:16:09,160
What is that like 3000 basis 
points, right or whatever. 

1220
01:16:09,160 --> 01:16:13,520
It's absurd rake. 
It's just crazy that for like 

1221
01:16:13,520 --> 01:16:16,800
20, you know, 20 years now that 
they been able to get away with 

1222
01:16:16,800 --> 01:16:18,960
it. 
So to me that like massive, 

1223
01:16:19,920 --> 01:16:22,800
massive rake that they take 
seems like an opportunity 

1224
01:16:22,800 --> 01:16:27,120
because if devs have can't 
distribute to crypto users and 

1225
01:16:27,120 --> 01:16:30,800
there's enough high spending 
users in that distribution 

1226
01:16:30,800 --> 01:16:34,280
channel, they will actually look
at their like top 1% users that 

1227
01:16:34,280 --> 01:16:36,440
are the spendiest users in iOS 
or Android. 

1228
01:16:36,640 --> 01:16:39,720
I'll literally give them a the 
phone for free or like offer 

1229
01:16:39,720 --> 01:16:42,080
them incentives like through air
drops or whatever. 

1230
01:16:42,440 --> 01:16:45,200
That that's the hope that we can
get that flywheel work working. 

1231
01:16:45,280 --> 01:16:49,040
If it if it works, then that's 
like a huge opportunity. 

1232
01:16:49,480 --> 01:16:52,840
How how strong will be the 
connection between the phone and

1233
01:16:52,840 --> 01:16:54,760
the chain? 
I mean I assume there will be by

1234
01:16:54,760 --> 01:16:57,280
default wallet on the on the 
phone. 

1235
01:16:57,280 --> 01:17:00,280
Yeah, there's there's an 
embedded wallet and an enclave 

1236
01:17:00,280 --> 01:17:03,400
to run the seed phrase and 
there's a bunch of work to kind 

1237
01:17:03,400 --> 01:17:06,800
of unify the experience so 
people don't have to switch UI. 

1238
01:17:06,800 --> 01:17:10,520
It's more like Apple Pay that 
that's the goal. 

1239
01:17:10,920 --> 01:17:14,800
I'm actually not like opposed to
adding Ethereum support or 

1240
01:17:14,800 --> 01:17:19,720
anything else in the future. 
It's just these are like 

1241
01:17:20,200 --> 01:17:22,280
iteration times with hardware so
long. 

1242
01:17:22,280 --> 01:17:24,840
So it seems like we've been at 
it for a while, but this is just

1243
01:17:24,840 --> 01:17:29,040
like the second release. 
It's in got it to keep the team 

1244
01:17:29,040 --> 01:17:32,040
focused and and ship, you know. 
And I assume technically it's 

1245
01:17:32,040 --> 01:17:34,760
it's it's based on Android or. 
Yeah, it's Android. 

1246
01:17:34,760 --> 01:17:39,960
Yeah, vanilla Android with the 
enclave kind of wallet signing 

1247
01:17:40,040 --> 01:17:42,920
feature at it. 
Yeah, I know. 

1248
01:17:42,920 --> 01:17:44,360
I mean, good luck with this 
initiative. 

1249
01:17:44,720 --> 01:17:50,600
Certainly think the reserves, 
yeah, should get more 

1250
01:17:50,600 --> 01:17:55,120
competition. 
If we lose because they compress

1251
01:17:55,120 --> 01:17:58,640
their fees, then that's the 
beauty of capitalism. 

1252
01:17:58,720 --> 01:18:03,440
Then that worked, right? 
Like a competitor was able to 

1253
01:18:03,440 --> 01:18:06,200
change the equilibrium in the 
market and that that's an 

1254
01:18:06,200 --> 01:18:08,720
awesome outcome. 
Cool. 

1255
01:18:08,800 --> 01:18:11,200
Well, thank you so much for 
coming on and totally it was 

1256
01:18:11,200 --> 01:18:16,200
really great to have you and 
super excited about the Solana 

1257
01:18:16,200 --> 01:18:20,640
Road map and the pace at which 
the ecosystem is moving and you 

1258
01:18:20,640 --> 01:18:22,280
know all of the things that are 
ahead. 

1259
01:18:23,800 --> 01:18:25,480
Thanks for having me, this was 
super fun.