1
00:00:00,160 --> 00:00:04,000
Our initial thinking was we 
should write financial contracts

2
00:00:04,000 --> 00:00:06,600
on a blockchain, it makes them 
globally accessible. 

3
00:00:06,920 --> 00:00:10,200
Whereas financial contracts in 
Tradfi, you know, you have to be

4
00:00:10,200 --> 00:00:13,840
part of the legal jurisdiction 
of country XYZ. 

5
00:00:14,000 --> 00:00:19,760
Well, we need an Oracle to be 
able to resolve the data about 

6
00:00:20,000 --> 00:00:22,680
like what the output outcome of 
this financial contract should 

7
00:00:22,680 --> 00:00:25,440
be. 
We are inspired by things like 

8
00:00:25,440 --> 00:00:29,880
Vitalik's Shell and Coin blog 
post from 2014 and various like 

9
00:00:29,880 --> 00:00:32,360
game theoretic concepts and 
crypto economic concepts. 

10
00:00:32,439 --> 00:00:33,840
But the core idea is pretty 
simple. 

11
00:00:34,000 --> 00:00:37,640
Anyone on the blockchain can 
propose a statement as true, and

12
00:00:37,640 --> 00:00:40,560
then there's a challenge period.
And anyone else on the 

13
00:00:40,560 --> 00:00:43,600
blockchain during that challenge
period could say, I disagree. 

14
00:00:43,840 --> 00:00:46,680
There's bonds and there's 
incentives here to both propose 

15
00:00:46,680 --> 00:00:49,160
correctly and to dispute 
correctly. 

16
00:00:49,400 --> 00:00:51,880
And there's penalties if you 
propose incorrectly or dispute 

17
00:00:51,880 --> 00:00:55,160
incorrectly too. 
Did is we're like our whole MO 

18
00:00:55,360 --> 00:00:59,000
is we want bridging to be a 2 
second or less experience. 

19
00:00:59,000 --> 00:01:02,360
We want it to be fast and cheap,
but we think like the speed is 

20
00:01:02,360 --> 00:01:05,519
critically important. 
Welcome to Epicentre, the show 

21
00:01:05,519 --> 00:01:07,520
which talks about the 
technologies, projects and 

22
00:01:07,520 --> 00:01:10,080
people driving decentralization 
and the blockchain revolution. 

23
00:01:10,080 --> 00:01:12,760
I'm Frederica Ans and today I'm 
speaking with Hart Lamper, who 

24
00:01:12,760 --> 00:01:17,000
is the Co founder of OMA and a 
Cross Protocol, which are two 

25
00:01:17,000 --> 00:01:22,240
interrelated projects in the 
wider Ethereum space. 

26
00:01:22,240 --> 00:01:26,640
So Uma is a decentralized 
optimistic Arkle and the cross 

27
00:01:26,640 --> 00:01:31,040
is a bridge that in some 
flavours uses Uma under the 

28
00:01:31,040 --> 00:01:33,720
hood, but we'll get it to that 
in in just a second. 

29
00:01:34,160 --> 00:01:37,400
Before I talk with Hart, let me 
tell you about our sponsors this

30
00:01:37,400 --> 00:01:40,000
week. 
If you're looking to stake your 

31
00:01:40,000 --> 00:01:43,040
crypto with confidence, look no 
further than Course one. 

32
00:01:43,520 --> 00:01:47,120
More than 150,000 delegators, 
including institutions like Bid 

33
00:01:47,120 --> 00:01:49,000
Go, Pantera Capital and Ledger 
Trust. 

34
00:01:49,000 --> 00:01:52,040
Course One with the assets. 
They support over 50 block 

35
00:01:52,040 --> 00:01:54,320
chains and are leaders in 
governance on networks like 

36
00:01:54,320 --> 00:01:57,440
Cosmos, ensuring your stake is 
responsibly managed. 

37
00:01:57,920 --> 00:02:00,760
Thanks to the advanced MEB 
research, you can also enjoy the

38
00:02:00,760 --> 00:02:03,920
highest staking rewards. 
You can stake directly from your

39
00:02:03,920 --> 00:02:07,360
preferred wallet, set up a white
label note, restake your assets 

40
00:02:07,360 --> 00:02:11,039
on Eigenia or Symbiotic, or use 
the SDK for multi chain staking 

41
00:02:11,039 --> 00:02:14,120
in your app. 
Learn more at Chorus .1 and 

42
00:02:14,120 --> 00:02:17,760
start staking today. 
Hey guys, I want to tell you 

43
00:02:17,760 --> 00:02:21,360
about Gnosis, a collective of 
builders creating real tools for

44
00:02:21,360 --> 00:02:22,920
real people on the open 
Internet. 

45
00:02:23,680 --> 00:02:25,520
Nosis has been around since 
2015. 

46
00:02:25,640 --> 00:02:28,680
In fact, it started as one of 
Etherium's very first projects, 

47
00:02:28,760 --> 00:02:31,800
and today it's grown to a whole 
ecosystem designed to make open 

48
00:02:31,800 --> 00:02:33,760
finance actually work for 
everyday people. 

49
00:02:34,480 --> 00:02:36,000
At the center of it all is Nosis
Chain. 

50
00:02:36,200 --> 00:02:38,720
It's a low cost, highly 
decentralized layer, one that's 

51
00:02:38,720 --> 00:02:42,000
compatible with Etherium and 
secured by over 300,000 

52
00:02:42,000 --> 00:02:43,760
validators. 
So whether you're building a 

53
00:02:43,760 --> 00:02:47,600
DAP, experimenting with Defy, or
working on autonomous agents, 

54
00:02:47,880 --> 00:02:51,040
Nosis Chain gives you a solid, 
neutral foundation to build on. 

55
00:02:51,960 --> 00:02:53,920
But Nosus is more than just 
infrastructure. 

56
00:02:54,160 --> 00:02:56,240
It's also tools that people can 
actually use. 

57
00:02:56,680 --> 00:02:59,080
Like Circles, for example. 
Let's anyone issue their own 

58
00:02:59,080 --> 00:03:02,120
digital currency through 
networks of trust, not banks. 

59
00:03:02,560 --> 00:03:05,000
And then there's Metri. 
It's their smart contract wallet

60
00:03:05,000 --> 00:03:07,800
that makes it easy to access 
circles, manage group 

61
00:03:07,800 --> 00:03:11,720
currencies, and even spend 
anywhere Visa is accepted thanks

62
00:03:11,720 --> 00:03:13,680
to their integration with Nosus 
Pay. 

63
00:03:14,400 --> 00:03:17,720
All this is governed by Nosus 
Dow, where anyone can propose, 

64
00:03:17,720 --> 00:03:21,320
vote and help guide the network.
And if you want to get involved,

65
00:03:21,680 --> 00:03:23,280
running a validator is super 
easy. 

66
00:03:23,600 --> 00:03:26,560
All you need is 1 GNO and some 
basic hardware. 

67
00:03:27,120 --> 00:03:29,840
To learn more and start building
on the open Internet, head to 

68
00:03:29,840 --> 00:03:34,240
gnosis dot IO Gnosis Building 
the Open Internet one Block at a

69
00:03:34,240 --> 00:03:37,680
time. 
So cool, hot, it's so nice to 

70
00:03:37,680 --> 00:03:39,920
have you on. 
Thank you so much for having me,

71
00:03:39,920 --> 00:03:43,080
good to be here. 
Incredible as it sounds, you've 

72
00:03:43,080 --> 00:03:45,640
never been on this podcast 
before, so your Co founder 

73
00:03:45,640 --> 00:03:50,520
Allison has been on. 
So maybe before we kind of dive 

74
00:03:50,520 --> 00:03:52,440
into kind of like all the 
awesome stuff that you're 

75
00:03:52,440 --> 00:03:55,320
building. 
Tell us about who you are and 

76
00:03:55,520 --> 00:03:58,440
how you got here. 
Sure. 

77
00:03:58,440 --> 00:04:00,680
Yeah, You know, I was looking 
back, I was actually trying to 

78
00:04:00,680 --> 00:04:03,200
remember if I'd been on 
Epicenter before like years ago.

79
00:04:03,200 --> 00:04:05,920
But you're right, it was 
Allison, my Co founder that that

80
00:04:06,200 --> 00:04:11,440
that was on here. 
PLDRI studied computer science. 

81
00:04:12,160 --> 00:04:15,120
I then worked in financial 
services at Goldman Sachs as a 

82
00:04:15,120 --> 00:04:18,399
bond trader like U.S. 
Treasury bonds in the financial 

83
00:04:18,399 --> 00:04:23,040
crisis. 
Allison was two years junior to 

84
00:04:23,040 --> 00:04:28,440
me and worked beside me for four
years there, something like 

85
00:04:28,440 --> 00:04:30,120
that. 
And we were very closely 

86
00:04:30,120 --> 00:04:31,960
together and that's how we got 
to know each other in the 1st 

87
00:04:31,960 --> 00:04:34,480
place. 
Trading bonds during the 

88
00:04:34,480 --> 00:04:36,480
financial crisis, U.S. 
Treasuries during the financial 

89
00:04:36,480 --> 00:04:39,240
crisis was super interesting. 
It's not my background, but I've

90
00:04:39,240 --> 00:04:41,360
learned a lot about finance. 
I learned about market 

91
00:04:41,360 --> 00:04:44,520
structure, learned a lot about 
actually incentive structures 

92
00:04:44,520 --> 00:04:46,960
and what incentivizes people 
come back to that. 

93
00:04:47,840 --> 00:04:50,880
I left to do a fintech business 
that weren't kind of sideways 

94
00:04:50,880 --> 00:04:53,360
got acquired by NASA manager 
four years later and then was 

95
00:04:53,360 --> 00:04:55,920
full time in crypto starting 
beginning of 2018. 

96
00:04:56,400 --> 00:05:01,560
And I recruited Allison to work 
with me on this decentralized 

97
00:05:01,560 --> 00:05:05,640
finance idea. 
Before D5 was a term, if we go 

98
00:05:05,640 --> 00:05:08,880
back to 2018, people hadn't 
really thought about that as a 

99
00:05:08,880 --> 00:05:11,160
concept yet. 
And Frederica, you'd remember 

100
00:05:11,160 --> 00:05:14,760
this from like Gnosis days too. 
It was just kind of like it was 

101
00:05:14,760 --> 00:05:16,600
all sort of researchy stuff, 
right? 

102
00:05:16,600 --> 00:05:19,440
Like what could, what kind of 
financial applications or 

103
00:05:19,440 --> 00:05:23,240
financial ideas could be built 
on smart contract platforms and 

104
00:05:23,240 --> 00:05:25,760
on Ethereum? 
Yeah, absolutely. 

105
00:05:25,760 --> 00:05:28,520
So kind of the thing that you 
guys started back then was 

106
00:05:28,520 --> 00:05:31,680
called Universal Market Access 
or UMA for short. 

107
00:05:32,280 --> 00:05:36,200
And you actually started with 
synthetic assets. 

108
00:05:36,760 --> 00:05:39,640
How how I mean you came from a 
trading background. 

109
00:05:39,640 --> 00:05:41,920
So kind of, I guess it kind of 
like it, it checks out. 

110
00:05:42,160 --> 00:05:47,120
But how did you land on this and
when did you kind of decide to 

111
00:05:47,120 --> 00:05:50,320
kind of pivot to kind of an 
Oracle? 

112
00:05:51,280 --> 00:05:53,680
Well, it's, it's, it's 
interesting to think about it 

113
00:05:53,680 --> 00:05:55,880
because in some ways we 
definitely pivoted and in other 

114
00:05:55,880 --> 00:06:00,240
ways it was just like kind of 
all the plan the whole way. 

115
00:06:01,200 --> 00:06:04,040
The, the way to think about this
or the way I like to think about

116
00:06:04,040 --> 00:06:09,800
it is our initial thinking was 
we should write financial 

117
00:06:09,800 --> 00:06:12,880
contracts on a blockchain that 
makes all the sense in the 

118
00:06:12,880 --> 00:06:15,400
world. 
It also, it makes them globally 

119
00:06:15,400 --> 00:06:18,000
accessible. 
Whereas financial contracts in 

120
00:06:18,000 --> 00:06:21,480
Tradfi, you know, you have to be
part of the legal jurisdiction 

121
00:06:21,520 --> 00:06:25,400
of country XYZ to, to have 
access to that financial product

122
00:06:25,400 --> 00:06:28,760
or service. 
So you know, the name universal 

123
00:06:28,760 --> 00:06:31,640
market access was all about how 
do we make finance globally 

124
00:06:31,640 --> 00:06:34,200
accessible? 
Well, we need a enforcement 

125
00:06:34,200 --> 00:06:36,040
mechanism that is globally 
accessible. 

126
00:06:36,320 --> 00:06:39,400
A blockchain actually can do 
that pretty well with economic 

127
00:06:39,400 --> 00:06:41,120
incentives. 
OK. 

128
00:06:41,120 --> 00:06:43,280
So we like this idea of 
financial contracts. 

129
00:06:43,280 --> 00:06:45,360
You could call them derivatives.
Derivatives are just financial 

130
00:06:45,360 --> 00:06:47,280
contracts, right? 
But we wanted to do that on a 

131
00:06:47,280 --> 00:06:50,080
blockchain. 
And we're like, well, we need an

132
00:06:50,120 --> 00:06:55,840
Oracle to be able to resolve the
data about like what the output 

133
00:06:55,920 --> 00:06:57,720
outcome of this financial 
contract should be. 

134
00:06:58,760 --> 00:07:01,920
Concrete example, like you and I
do a binary bet on whether the 

135
00:07:01,920 --> 00:07:04,600
price of Bitcoin will be above 
or below 100K. 

136
00:07:04,880 --> 00:07:07,760
We need to know whether that's 
true or not, etcetera. 

137
00:07:08,680 --> 00:07:11,960
So that's where we like came up 
with this Oracle design that we 

138
00:07:11,960 --> 00:07:13,760
were super excited about early 
on. 

139
00:07:14,920 --> 00:07:17,680
Then though, we needed a use 
case and we're like, OK, it's 

140
00:07:17,680 --> 00:07:20,440
super early days. 
Like we need something for 

141
00:07:20,440 --> 00:07:22,600
somebody to use. 
It's super early days of crypto.

142
00:07:22,920 --> 00:07:26,480
Nobody wants to like trade 
financial derivatives yet. 

143
00:07:26,480 --> 00:07:30,360
That's like too sophisticated. 
We were like, let's make tokens.

144
00:07:30,360 --> 00:07:34,800
People like tokens. 
Let's make tokens that look like

145
00:07:34,800 --> 00:07:37,720
financial contracts. 
There are derivative contracts, 

146
00:07:38,000 --> 00:07:41,720
there's synthetic make assets is
what we did, synthetic assets 

147
00:07:41,720 --> 00:07:46,800
that track some other underlying
object and we can use our Oracle

148
00:07:46,800 --> 00:07:49,400
to power that. 
So it's kind of the path there 

149
00:07:49,560 --> 00:07:52,240
of how we got into into that 
space at the time. 

150
00:07:53,440 --> 00:07:56,200
Yeah, super interesting. 
It's funny how kind of sometimes

151
00:07:56,200 --> 00:07:58,480
you start doing one thing and 
then kind of like you, you, you 

152
00:07:58,480 --> 00:08:02,720
need to build like part parts to
kind of power this. 

153
00:08:02,720 --> 00:08:05,120
And then kind of like the, the, 
the parts that power this kind 

154
00:08:05,120 --> 00:08:07,680
of become your, your main thing 
kind of later. 

155
00:08:07,880 --> 00:08:09,520
And this kind of happened again,
right? 

156
00:08:09,520 --> 00:08:12,320
So kind of like you, you guys 
have since launched a cross, 

157
00:08:12,480 --> 00:08:18,280
which also kind of came out from
the UMA ecosystem and across is 

158
00:08:18,280 --> 00:08:20,920
a bridge kind of like which 
which is already kind of clear 

159
00:08:20,920 --> 00:08:22,840
from the name. 
But what prompted this? 

160
00:08:23,960 --> 00:08:28,760
So honestly, we wanted more use 
cases for the Yuma Oracle and we

161
00:08:28,800 --> 00:08:30,240
did. 
Basically it was an internal 

162
00:08:30,240 --> 00:08:33,000
hackathon again. 
There might be like Gnosis 

163
00:08:33,000 --> 00:08:35,360
parallels here too, because you 
guys also came to spawn up a 

164
00:08:35,360 --> 00:08:39,039
bunch of ideas along the way. 
And actually we always kind of 

165
00:08:39,039 --> 00:08:43,240
looked at you guys for 
inspiration that way, but we 

166
00:08:43,240 --> 00:08:46,160
wanted more use cases for this 
UMA Oracle. 

167
00:08:46,400 --> 00:08:49,040
And we're like, OK, the 
synthetic assets, they weren't 

168
00:08:49,080 --> 00:08:52,160
really taking off. 
This is, you know, four years 

169
00:08:52,160 --> 00:08:56,240
ago, 3-4 years ago. 
People want to trade crypto 

170
00:08:56,240 --> 00:08:58,360
assets, not, you know, synthetic
assets. 

171
00:08:58,360 --> 00:09:00,360
That might actually be changing 
right now. 

172
00:09:00,560 --> 00:09:04,080
We'll see. 
But but we're like, we have this

173
00:09:04,080 --> 00:09:08,360
really interesting Oracle that 
can give you give you data on 

174
00:09:08,360 --> 00:09:11,760
anything. 
It it can even give you data on 

175
00:09:11,760 --> 00:09:17,200
what's happening on an L2 faster
than the seven day bridge is 

176
00:09:17,200 --> 00:09:19,400
going to let you get data from 
that L2. 

177
00:09:19,920 --> 00:09:24,120
And we actually use this as an 
internal hackathon to build a 

178
00:09:24,120 --> 00:09:29,680
fast exit bridge from optimism. 
It went One Direction only. 

179
00:09:29,800 --> 00:09:31,920
It went it only let you get off 
optimism. 

180
00:09:31,920 --> 00:09:33,560
This is the first internal 
hackathon. 

181
00:09:34,880 --> 00:09:38,040
And then we're like, yeah, you 
know, there's something here. 

182
00:09:38,480 --> 00:09:41,960
And then we thought about it a 
lot harder, came up with this 

183
00:09:41,960 --> 00:09:44,600
these early like intent based 
designs, which I'm sure we'll 

184
00:09:44,600 --> 00:09:47,920
get into and realized that we 
had a really compelling product 

185
00:09:48,520 --> 00:09:53,280
in this super fast intent based 
bridge to connect mostly EVM 

186
00:09:53,280 --> 00:09:58,360
chains and then launched across 
as like something that used UMA 

187
00:09:58,480 --> 00:10:01,960
in the wild. 
Yeah, super interesting. 

188
00:10:01,960 --> 00:10:05,240
Maybe maybe because kind of 
maybe we go sequentially here. 

189
00:10:05,240 --> 00:10:07,080
So maybe let's talk about Uma 
first. 

190
00:10:07,080 --> 00:10:10,560
So kind of Uma, you already 
alluded to this, so kind of it's

191
00:10:10,560 --> 00:10:13,800
an optimistic article. 
So what does this mean and how 

192
00:10:13,800 --> 00:10:18,000
does it differ from more 
traditional ARCA? 

193
00:10:18,000 --> 00:10:21,240
It's like chain link. 
I mean, chain link does a few 

194
00:10:21,240 --> 00:10:23,080
things now too, to be fair to 
them. 

195
00:10:23,080 --> 00:10:27,280
But the, the classic version of 
chain link is we're going to 

196
00:10:27,280 --> 00:10:32,040
have a, a series of nodes or 
some, some set of nodes write 

197
00:10:32,040 --> 00:10:35,160
price data to a blockchain. 
And so it's, it's very 

198
00:10:35,160 --> 00:10:38,240
constrained in that it will like
only write the price data that 

199
00:10:38,240 --> 00:10:42,840
those nodes know to write. 
Works great for Bitcoin prices, 

200
00:10:42,840 --> 00:10:44,320
Ethereum prices, that kind of 
stuff. 

201
00:10:45,840 --> 00:10:48,680
OK, cool. 
But we were trying to solve the 

202
00:10:48,680 --> 00:10:52,680
generalized problem of we want 
to get any bit of data onto any 

203
00:10:52,680 --> 00:10:54,760
bit of verifiable data onto a 
blockchain. 

204
00:10:56,640 --> 00:11:00,320
And we're like, OK, well, we 
need a different system to do 

205
00:11:00,320 --> 00:11:03,480
this. 
We are inspired by things like 

206
00:11:03,480 --> 00:11:09,080
Vitalik's shell and coin blog 
post from 2014 and various like 

207
00:11:09,080 --> 00:11:11,600
game theoretic concepts and 
crypto economic concepts. 

208
00:11:12,160 --> 00:11:13,680
But the core idea is pretty 
simple. 

209
00:11:13,800 --> 00:11:18,160
We say, hey, anyone on anyone on
the blockchain can propose a 

210
00:11:18,160 --> 00:11:21,120
statement as true. 
So they could propose, we'll 

211
00:11:21,120 --> 00:11:23,720
take an election. 
They could propose Trump won the

212
00:11:23,720 --> 00:11:27,040
election and then there's a 
challenge period. 

213
00:11:27,280 --> 00:11:30,920
And anyone, anyone else on the 
blockchain during that challenge

214
00:11:30,920 --> 00:11:33,440
period could say, I disagree, 
right? 

215
00:11:34,680 --> 00:11:37,760
First step, the happy path, the 
optimistic path is nobody 

216
00:11:37,760 --> 00:11:41,280
disagrees. 
And so then that, that that 

217
00:11:41,280 --> 00:11:46,440
proposal gets taken as true. 
And there's, there's bonds and 

218
00:11:46,440 --> 00:11:50,760
there's incentives here to both 
propose correctly and to dispute

219
00:11:50,760 --> 00:11:52,640
correctly. 
And there's penalties if you 

220
00:11:52,640 --> 00:11:54,760
propose incorrectly or dispute 
incorrectly too. 

221
00:11:55,480 --> 00:11:57,040
So we have incentives lined up 
there. 

222
00:11:57,200 --> 00:12:00,920
But it's a very simple kind of 
challenge game where anyone can 

223
00:12:00,920 --> 00:12:04,040
say this is what I know to be 
true and anyone else on the 

224
00:12:04,040 --> 00:12:07,440
blockchain can say I disagree. 
That's that's the core concept. 

225
00:12:08,400 --> 00:12:14,400
Walk me through what happens if 
I post an untrue statement and 

226
00:12:14,400 --> 00:12:18,800
someone calls me out on it. 
How how I assume kind of I get a

227
00:12:18,800 --> 00:12:22,200
chance to kind of redeem myself 
or prove that kind of like what 

228
00:12:22,200 --> 00:12:25,960
I stated initially was actually 
true or how how, how, how does 

229
00:12:25,960 --> 00:12:27,880
is there some sort of escalation
mechanism here? 

230
00:12:28,400 --> 00:12:30,920
Yeah. 
So you don't necessarily get a 

231
00:12:30,920 --> 00:12:32,640
chance. 
You and everyone else can decide

232
00:12:32,640 --> 00:12:34,200
who's right. 
But like, let's let's go 

233
00:12:34,200 --> 00:12:38,400
concretely. 
So Fredrique, you propose that 

234
00:12:38,840 --> 00:12:41,600
Harris won the election. 
We'll use that example. 

235
00:12:42,520 --> 00:12:44,560
And you have to post a bond to 
do that. 

236
00:12:44,640 --> 00:12:47,880
The bond can be a parameter of 
the protocol of the system. 

237
00:12:48,200 --> 00:12:49,600
But you post a bond to say do 
that. 

238
00:12:49,600 --> 00:12:53,960
Let's say it's $1000. 
And then I can be like, 

239
00:12:53,960 --> 00:12:56,000
actually, I disagree with you. 
I think that's untrue. 

240
00:12:56,320 --> 00:13:00,320
I post a matching bond of $1000 
to dispute you and say this is 

241
00:13:00,320 --> 00:13:03,880
untrue. 
OK, so first thing that Ooma 

242
00:13:03,880 --> 00:13:08,400
does is now that there's a 
dispute that data won't get used

243
00:13:08,400 --> 00:13:12,160
in the underlying contract, 
we're going to have to wait. 

244
00:13:12,160 --> 00:13:14,840
We wait until somebody proposes 
in a way that doesn't get 

245
00:13:14,840 --> 00:13:17,720
challenged to use that data in 
the underlying contract. 

246
00:13:18,040 --> 00:13:22,320
So this is mostly true. 
So if it was Polymarket right 

247
00:13:22,320 --> 00:13:25,840
now, Polymark would be like, OK,
we we're not going to use your 

248
00:13:25,840 --> 00:13:28,520
proposal that Harris one. 
We're going to wait for another 

249
00:13:28,520 --> 00:13:33,040
proposal later on, but we still 
need to resolve between two of 

250
00:13:33,040 --> 00:13:36,320
us who was right to figure out 
where we get those bonds. 

251
00:13:36,560 --> 00:13:39,680
Do the $2000 worth of bonds go 
to you or do they go to me? 

252
00:13:41,400 --> 00:13:43,920
And so then this is where we 
lean into like Vitalik's 

253
00:13:43,920 --> 00:13:48,720
shelling coin blog post ideas 
where and this is also a lot of 

254
00:13:48,720 --> 00:13:51,920
concepts from Auger and Gnosis 
and early prediction market type

255
00:13:51,920 --> 00:13:54,400
stuff too. 
But we go and we say to all our 

256
00:13:54,400 --> 00:13:58,960
token holders, they, they go 
through a 2 step voting process 

257
00:13:58,960 --> 00:14:03,080
where they vote in secret what 
they believe is true, whether 

258
00:14:03,080 --> 00:14:05,480
your proposal or my dispute or 
it was correct. 

259
00:14:07,560 --> 00:14:11,120
And they, they, they vote in 
secret and then they reveal all 

260
00:14:11,120 --> 00:14:14,960
at once. 
And the game theory and 

261
00:14:14,960 --> 00:14:18,160
economics of this design are 
such that you're incentivized to

262
00:14:18,160 --> 00:14:23,200
vote your own beliefs, your own 
truth, and the majority will get

263
00:14:23,200 --> 00:14:26,960
rewarded with with a reward at 
the expense of the of the 

264
00:14:26,960 --> 00:14:30,120
minority that voted against the 
majority outcome. 

265
00:14:30,960 --> 00:14:35,200
And so we use this shelling 
point concept to resolve who out

266
00:14:35,200 --> 00:14:38,080
of the two of us was correct by 
having this distributed 

267
00:14:38,080 --> 00:14:43,440
decentralized voter base here. 
OK, there's, there's several 

268
00:14:43,440 --> 00:14:46,640
super interesting things here. 
So kind of is it possible that 

269
00:14:46,640 --> 00:14:50,400
kind of like sometimes there are
situations where you are 

270
00:14:50,520 --> 00:14:53,560
incentivized to actually vote 
against your beliefs just 

271
00:14:53,560 --> 00:14:57,080
because you know what the other 
people's beliefs are like? 

272
00:14:57,080 --> 00:15:01,720
So kind of for instance, I give 
you, I give you, I give you an 

273
00:15:01,720 --> 00:15:05,840
example also say the COVID lab 
hypothesis, right? 

274
00:15:05,840 --> 00:15:09,120
So kind of like early on, kind 
of like there was there was 

275
00:15:09,120 --> 00:15:13,520
already very vocal kind of 
minority who kind of who were 

276
00:15:13,760 --> 00:15:18,680
who was advocating for this. 
And kind of as time went on, 

277
00:15:19,320 --> 00:15:22,280
it's turned out that kind of 
like they weren't crazy. 

278
00:15:22,280 --> 00:15:26,000
And maybe maybe it, it, it is 
actually kind of a lab sort of 

279
00:15:26,000 --> 00:15:28,120
thing. 
But someone who would have known

280
00:15:28,240 --> 00:15:30,920
kind of like in the very 
beginning of COVID that this 

281
00:15:30,920 --> 00:15:34,760
kind of like this, this lab 
hypothesis was true. 

282
00:15:34,760 --> 00:15:37,080
Maybe because kind of like they 
were there on the ground or 

283
00:15:37,080 --> 00:15:40,680
maybe because it was them or 
whatever they were involved in 

284
00:15:40,880 --> 00:15:45,000
covering it up or, or however 
they kind of come to know this, 

285
00:15:45,280 --> 00:15:49,320
they would still have been 
incentivize to kind of vote 

286
00:15:49,320 --> 00:15:53,400
against what they truly believe 
because they know that this is 

287
00:15:53,400 --> 00:15:56,120
not a a consensus narrative, 
right? 

288
00:15:57,200 --> 00:15:58,640
Yeah. 
I mean, I think you picked a 

289
00:15:58,640 --> 00:16:02,360
very, very, very interesting 
example of where I think the 

290
00:16:03,920 --> 00:16:08,320
like, I think if you ran a long 
term prediction market over like

291
00:16:08,560 --> 00:16:13,160
the COVID lab leak theory, like 
you didn't let it resolve and 

292
00:16:13,160 --> 00:16:16,160
you kept kept letting it run, I 
think you'd see that prediction 

293
00:16:16,160 --> 00:16:19,760
market move a lot over, you 
know, a four year period, right?

294
00:16:20,600 --> 00:16:22,360
So it's a really, really 
interesting example. 

295
00:16:22,800 --> 00:16:32,480
What I would say is in, in 
theory, a voter, you can't trust

296
00:16:32,480 --> 00:16:34,960
what other voters say they're 
going to vote. 

297
00:16:35,480 --> 00:16:40,280
They actually have an incentive 
to frankly lie to you because if

298
00:16:40,280 --> 00:16:42,720
they get you to vote in the 
minority, they get a bigger 

299
00:16:42,720 --> 00:16:47,200
reward if they're the majority. 
So there is this like a 

300
00:16:47,200 --> 00:16:52,080
purposefully built PvP kind of 
mechanism within the voting game

301
00:16:52,080 --> 00:16:55,680
itself where other voters are 
supposed to. 

302
00:16:55,720 --> 00:16:59,080
Like they literally have the 
game theoretic incentive to tell

303
00:16:59,080 --> 00:17:01,400
you that they're going to vote 
the opposite of how they 

304
00:17:01,400 --> 00:17:05,640
actually do vote. 
And so, you know, the, the 

305
00:17:05,640 --> 00:17:08,640
theory behind this is if you 
understand how this all works 

306
00:17:08,640 --> 00:17:11,880
and or if you don't, you're 
supposed to just be like, OK, I 

307
00:17:11,880 --> 00:17:14,079
don't know what the noise out 
there is saying. 

308
00:17:14,359 --> 00:17:17,520
I'm going to do my own research,
come to my own conclusion, and 

309
00:17:17,520 --> 00:17:21,160
vote my own beliefs because I 
don't really know at all with 

310
00:17:21,200 --> 00:17:23,720
any kind of certainty what 
others are going to say. 

311
00:17:25,079 --> 00:17:27,640
Now, there's a whole bunch of 
probably very interesting, like 

312
00:17:27,640 --> 00:17:29,880
philosophical and theoretical 
thoughts here too. 

313
00:17:30,120 --> 00:17:33,520
Like again, the lab leak example
is something that I think is 

314
00:17:33,520 --> 00:17:36,840
fascinating because, you know, 
personally, I was, I thought 

315
00:17:37,560 --> 00:17:40,840
myself that the lab leak theory 
was kind of crazy early on. 

316
00:17:41,240 --> 00:17:43,480
And then my own beliefs evolved 
over time. 

317
00:17:43,720 --> 00:17:46,080
And now I like, I probably have 
to do a bunch more research to 

318
00:17:46,080 --> 00:17:48,440
come to my own beliefs, but I 
don't think it's crazy anymore, 

319
00:17:48,480 --> 00:17:51,160
let's put it that way. 
So it's a, it's a very 

320
00:17:51,160 --> 00:17:53,920
interesting example. 
But at the point in time, I 

321
00:17:53,920 --> 00:17:57,040
think at any point in time when 
these votes come on, voters 

322
00:17:57,040 --> 00:17:59,720
really do have the game theory 
to vote their own true beliefs 

323
00:18:00,960 --> 00:18:02,760
because they don't know what 
other people are actually going 

324
00:18:02,760 --> 00:18:05,640
to do. 
What happens if you don't vote? 

325
00:18:05,680 --> 00:18:08,720
Are you penalized? 
Yeah, you penalized, you 

326
00:18:08,720 --> 00:18:12,320
penalized less, right? 
So the penalties here are also 

327
00:18:13,240 --> 00:18:14,560
they're parameters of the 
system. 

328
00:18:14,560 --> 00:18:16,800
There's probably a lot more 
modeling we can do to figure out

329
00:18:16,800 --> 00:18:19,920
how to optimally set them. 
But the penalties aren't like 

330
00:18:19,920 --> 00:18:23,440
100% or not. 
It's not like I vote and I lose 

331
00:18:23,800 --> 00:18:26,280
all my voting tokens if I vote 
incorrectly. 

332
00:18:27,160 --> 00:18:30,720
Like I we want to design the 
penalties so there's a strong 

333
00:18:30,720 --> 00:18:33,360
incentive to do your own 
research and vote correctly. 

334
00:18:34,760 --> 00:18:37,280
And we want to design the 
penalties so there's a strong 

335
00:18:37,280 --> 00:18:41,720
incentive to have people 
continue to vote and show up all

336
00:18:41,720 --> 00:18:45,960
the time, but not so much of an 
incentive that, you know, if I 

337
00:18:45,960 --> 00:18:48,800
miss a vote or two, it's so 
painful that I exit the system 

338
00:18:49,200 --> 00:18:52,160
and stop participating. 
OK, that's fair. 

339
00:18:52,280 --> 00:18:54,920
So let's go back to the to the 
Harris example. 

340
00:18:54,920 --> 00:18:58,880
So I posted the Harris one the 
the presidential election 

341
00:18:59,240 --> 00:19:01,960
statement. 
You contested this and kind of 

342
00:19:01,960 --> 00:19:04,880
there was a vote that kind of 
confirmed that you're right. 

343
00:19:05,360 --> 00:19:11,440
Is this statement now kind of in
the in the in the negated form 

344
00:19:11,440 --> 00:19:16,560
usable kind of as an input for 
smart contracts or is it is it 

345
00:19:16,560 --> 00:19:19,800
tainted and we have to have a 
new new vote? 

346
00:19:20,480 --> 00:19:24,160
This is this is up to this is up
to the integrator that wants to 

347
00:19:24,160 --> 00:19:27,160
like use this Oracle like they 
could go either way. 

348
00:19:27,520 --> 00:19:30,440
I prefer the design because this
voting process also takes a 

349
00:19:30,440 --> 00:19:33,200
while, right? 
So one of the things that we've 

350
00:19:33,200 --> 00:19:37,040
seen with Polymarket, for 
example, is somebody will 

351
00:19:37,040 --> 00:19:40,480
propose an answer. 
They often they propose the 

352
00:19:40,480 --> 00:19:43,440
answer too early. 
They're like like a sports game 

353
00:19:43,440 --> 00:19:45,520
is a good example. 
They propose that someone's 

354
00:19:45,520 --> 00:19:47,880
going to win the sports game, 
but they propose like 5 minutes 

355
00:19:47,880 --> 00:19:51,080
before the end of the game. 
And you're like, even if that 

356
00:19:51,080 --> 00:19:55,000
team they proposed did win, you 
kind of can't be like we can't 

357
00:19:55,000 --> 00:19:56,960
say like it's OK to propose 5 
minutes early. 

358
00:19:56,960 --> 00:19:59,920
Like what? 
It could have turned around, 

359
00:20:00,080 --> 00:20:01,160
right? 
So. 

360
00:20:02,000 --> 00:20:04,760
That will get disputed and it'll
go through this voting process, 

361
00:20:05,520 --> 00:20:09,200
but we don't want that that 
Polymarket market to sit there 

362
00:20:09,200 --> 00:20:11,240
and wait for this resolution 
process. 

363
00:20:11,440 --> 00:20:15,120
So we'll have somebody else 
propose a second proposal that 

364
00:20:15,120 --> 00:20:18,440
doesn't get disputed because 
it's after the game completed 

365
00:20:18,440 --> 00:20:21,120
and it has the right answer. 
So that's like an implementation

366
00:20:21,120 --> 00:20:24,200
decision of like how Polymarket 
would use the Oracle in this 

367
00:20:24,200 --> 00:20:26,400
example. 
I prefer it. 

368
00:20:26,400 --> 00:20:32,040
I prefer the idea of you only 
take as truth undisputed markets

369
00:20:32,040 --> 00:20:36,680
that are not tainted and the, 
the dispute process, sorry, the 

370
00:20:36,680 --> 00:20:40,920
voting process is really to 
resolve disputes and like where 

371
00:20:40,920 --> 00:20:44,040
the bonds go, I prefer that 
cause the economic security 

372
00:20:44,040 --> 00:20:47,480
behind that is like much, much 
deeper in many ways. 

373
00:20:48,080 --> 00:20:50,560
But it's a primer. 
It's it's up to the integration 

374
00:20:50,560 --> 00:20:53,400
decisions of the protocol. 
OK. 

375
00:20:53,400 --> 00:21:00,360
But in in that in that design, 
you could have kind of like say 

376
00:21:00,360 --> 00:21:05,040
500 statements that kind of 
speak to one question and 499 

377
00:21:05,040 --> 00:21:08,840
say no one says yes, it still 
get it goes kind of like 

378
00:21:09,160 --> 00:21:11,840
unchallenged somehow because 
people missed it. 

379
00:21:12,120 --> 00:21:16,480
And despite the fact that almost
all of them kind of .1 way you 

380
00:21:16,600 --> 00:21:19,760
you could you would you don't 
actually have to wait for kind 

381
00:21:19,760 --> 00:21:21,920
of like any dispute to be 
resolved. 

382
00:21:22,800 --> 00:21:28,000
You can already kind of use the 
one yes statement to resolve 

383
00:21:28,000 --> 00:21:30,400
right? 
Sorry walk me through this. 

384
00:21:30,400 --> 00:21:33,480
How do you where the 500? 
So there's, there's so kind of 

385
00:21:33,520 --> 00:21:39,120
say there's 500 people kind of 
like post an answer to post a 

386
00:21:39,120 --> 00:21:43,440
statement who who won the 
election. 

387
00:21:43,800 --> 00:21:48,480
So say 500 kind of say Harrison,
kind of like 499 of those get 

388
00:21:48,480 --> 00:21:51,200
contested. 
And one just kind of gets missed

389
00:21:51,200 --> 00:21:54,800
by by by kind of the because 
kind of like there's, there's 

390
00:21:54,800 --> 00:21:57,640
also attrition here, right? 
Kind of for the, for the, 

391
00:21:57,840 --> 00:21:59,560
because it's an optimistic 
system. 

392
00:22:00,280 --> 00:22:02,720
Yeah, there's sort of a DOS 
vector is kind of what you're, 

393
00:22:02,760 --> 00:22:06,320
you're, you're kind of like, 
yeah, spamming the system to 

394
00:22:06,320 --> 00:22:08,040
kind of overwhelm it. 
Yeah. 

395
00:22:08,280 --> 00:22:13,040
So I'm going, I'm skipping over 
some details like I should in 

396
00:22:13,040 --> 00:22:16,520
polling markets implementation 
at least you couldn't have they 

397
00:22:16,520 --> 00:22:18,880
wanted to let you have 500 
proposals for the same market 

398
00:22:19,400 --> 00:22:22,320
for these same reasons. 
So it's kind of like anyone can 

399
00:22:22,320 --> 00:22:25,360
propose the first one, anyone 
can propose the second one. 

400
00:22:25,600 --> 00:22:29,120
After the second proposal, we 
actually wait for the resolution

401
00:22:29,120 --> 00:22:31,480
of the voting cycle. 
And then other people, there's 

402
00:22:31,480 --> 00:22:36,080
like stuff that we do to, to 
kind of makes your eyes are 

403
00:22:36,080 --> 00:22:38,760
focused on the right markets 
because you're, you're right. 

404
00:22:38,760 --> 00:22:42,120
Otherwise you kind of have like 
you can kind of just spam and 

405
00:22:42,120 --> 00:22:44,800
overwhelm people. 
And if there's actually humans 

406
00:22:44,800 --> 00:22:48,640
voting on this, there are 
practical like human, human 

407
00:22:48,640 --> 00:22:52,680
bandwidth constraints about what
you can take care of, which, you

408
00:22:52,680 --> 00:22:55,360
know, like as polling, market 
scaling and other use cases are 

409
00:22:55,360 --> 00:22:57,280
scaling. 
And you and I talked about this 

410
00:22:57,280 --> 00:23:00,400
very briefly out of the podcast.
There's lots and lots of use 

411
00:23:00,400 --> 00:23:04,480
cases of where LLMS and AI can 
potentially scale this much 

412
00:23:04,480 --> 00:23:07,680
better, which I find super 
compelling and interesting. 

413
00:23:09,120 --> 00:23:11,320
But yes, your your example is a 
fair one. 

414
00:23:11,320 --> 00:23:13,520
And we have to put constraints 
around this this too. 

415
00:23:14,240 --> 00:23:17,480
Can I grief kind of the market 
creators or the people who have 

416
00:23:17,480 --> 00:23:23,520
market money on the market by 
creating 2 conflicting or two 

417
00:23:24,040 --> 00:23:27,320
wrong statements and kind of 
like just making sure that kind 

418
00:23:27,320 --> 00:23:29,800
of they incur the opportunity 
cost of not being able to kind 

419
00:23:29,800 --> 00:23:31,280
of get their capital out of the 
market? 

420
00:23:32,080 --> 00:23:35,400
Polling market does not allow 
permissionless market creation 

421
00:23:35,480 --> 00:23:40,960
at right now make that I I can't
speak for them. 

422
00:23:40,960 --> 00:23:43,480
I don't want to speak for them, 
but like one reason might be 

423
00:23:43,480 --> 00:23:46,840
this problem, right? 
And I if you go back and I think

424
00:23:46,840 --> 00:23:49,320
you ELO, you don't you 
experience with this, but we 

425
00:23:49,320 --> 00:23:52,280
look at Auger and other examples
and you know, if you have a 

426
00:23:52,280 --> 00:23:54,800
bunch of very similar markets, 
it also leads to this kind of 

427
00:23:54,800 --> 00:23:56,880
fragmentation of attention 
problem. 

428
00:23:58,360 --> 00:23:59,720
I think it's a hard problem to 
solve. 

429
00:24:00,520 --> 00:24:05,880
Again, I think you could going 
forward, if, if I were to design

430
00:24:05,880 --> 00:24:08,920
like a permission less 
prediction market kind of system

431
00:24:08,920 --> 00:24:13,040
here, I think you could use an 
AI to validate like, are these 

432
00:24:13,040 --> 00:24:16,120
markets similar and then not 
allow the creation of markets 

433
00:24:16,120 --> 00:24:19,160
that are like super close. 
But I think these are, these are

434
00:24:19,160 --> 00:24:22,080
all the problems that production
markets like have to solve to 

435
00:24:22,080 --> 00:24:25,720
keep scaling and growing. 
So I think you, you know, you 

436
00:24:25,720 --> 00:24:27,880
have a lot of experience and 
personal interest in this, I 

437
00:24:27,880 --> 00:24:32,640
think. 
And yeah, it's it's a good 

438
00:24:32,640 --> 00:24:35,480
question, but that's why 
Polymarket doesn't let anyone do

439
00:24:35,480 --> 00:24:40,360
it right now. 
You could also kind of tie the 

440
00:24:41,160 --> 00:24:45,200
amount of the bond you have to 
put to the amount of money in 

441
00:24:45,200 --> 00:24:46,640
the market. 
So they're kind of like you 

442
00:24:46,640 --> 00:24:50,040
can't do it at a flat rate. 
You kind of it, it, it at least 

443
00:24:50,040 --> 00:24:53,520
kind of like costs you kind of a
proportion of the funds you're 

444
00:24:53,520 --> 00:24:55,120
tying up well. 
I was just going to say the last

445
00:24:55,240 --> 00:24:57,200
point I'd make. 
The The thing is interesting is 

446
00:24:57,200 --> 00:25:01,120
like with prediction markets. 
So again, the UMA Oracle does a 

447
00:25:01,120 --> 00:25:03,600
lot more than just prediction 
markets, but that's what we've 

448
00:25:03,600 --> 00:25:05,800
been. 
We're really the like kind of 

449
00:25:05,840 --> 00:25:09,920
the only Oracle type being used 
in production at scale that does

450
00:25:10,040 --> 00:25:13,120
prediction market type stuff. 
But the thing that I found 

451
00:25:13,120 --> 00:25:15,880
interesting over the years and 
years of kind of doing this is 

452
00:25:15,880 --> 00:25:18,520
there's the theory and then 
there's like the practical 

453
00:25:18,520 --> 00:25:21,080
implementations. 
And there's a bunch of 

454
00:25:21,080 --> 00:25:25,800
heuristics here too that I think
are like where it's not obvious 

455
00:25:25,960 --> 00:25:28,120
from a pure theory or research 
perspective. 

456
00:25:28,360 --> 00:25:32,440
You've got to like do this kind 
of like glue and Band-Aid type 

457
00:25:32,440 --> 00:25:36,240
stuff to to keep things working 
effectively. 

458
00:25:36,800 --> 00:25:40,160
And you know, this is where I 
will give like Polymark deserves

459
00:25:40,160 --> 00:25:43,800
a lot of credit for figuring out
how to actually grow and scale 

460
00:25:43,800 --> 00:25:46,760
these markets. 
And even since the election, 

461
00:25:47,000 --> 00:25:50,400
they have figured out how to 
have many, many more markets 

462
00:25:50,400 --> 00:25:54,160
than they did six months ago and
have it like mostly work. 

463
00:25:55,040 --> 00:26:01,480
Yeah, yeah, I, I agree. 
What's your take on fine print 

464
00:26:01,480 --> 00:26:03,400
driven outcomes on friction 
market? 

465
00:26:03,400 --> 00:26:08,240
So for instance, kind of on 
auger kind of invalid outcome, 

466
00:26:08,360 --> 00:26:14,240
what was kind of a huge problem.
And when that kind of comes to 

467
00:26:14,240 --> 00:26:15,560
mind. 
Well, I actually think kind of 

468
00:26:15,560 --> 00:26:19,160
like Uma worked really well as 
an Oracle was kind of do you 

469
00:26:19,160 --> 00:26:23,560
remember that submarine that 
kind of sank and kind of there 

470
00:26:23,560 --> 00:26:28,280
was a market on polymarket with 
a submarine be found and clearly

471
00:26:28,280 --> 00:26:30,800
it wasn't found because kind of 
like it imploded, right? 

472
00:26:31,360 --> 00:26:35,320
But kind of somehow kind of, but
clearly that was not the intent 

473
00:26:35,440 --> 00:26:39,040
behind the market. 
So, and UMA actually resolved it

474
00:26:39,040 --> 00:26:44,320
to, yes, it was found and kind 
of I, I remember there was kind 

475
00:26:44,320 --> 00:26:49,800
of some upheaval on, on crypto 
Twitter about whether this was 

476
00:26:49,800 --> 00:26:51,960
the right call. 
I think, I think personally, 

477
00:26:52,120 --> 00:26:54,800
it's the call that I would have 
made because clearly that was 

478
00:26:54,800 --> 00:26:58,360
kind of the intent behind the 
market, but it's really 

479
00:26:58,640 --> 00:27:01,720
difficult. 
So what what's what's your take 

480
00:27:01,720 --> 00:27:04,480
on this kind of should Arcas 
weigh context or should they 

481
00:27:04,480 --> 00:27:06,400
just strictly enforce 
definitions? 

482
00:27:06,920 --> 00:27:11,680
Well, you, you can't strictly 
enforce definitions because the 

483
00:27:11,680 --> 00:27:16,840
English language or any language
is imperfect, right, Frederick 

484
00:27:16,880 --> 00:27:19,320
Like, it's so funny you brought 
out that example because I, I 

485
00:27:19,320 --> 00:27:22,360
agree with you personally. 
And like, you know, in the 

486
00:27:22,360 --> 00:27:25,040
moment, I don't have any opinion
and I don't vote or participate 

487
00:27:25,040 --> 00:27:28,520
in these markets myself at all. 
But there was a bunch of people 

488
00:27:28,520 --> 00:27:32,640
that are trying to argue that, 
you know, they found pieces of 

489
00:27:32,640 --> 00:27:37,280
the submarine, but they didn't 
find a big enough piece of the 

490
00:27:37,280 --> 00:27:41,960
capsule to fully confirm it was 
it imploded, right. 

491
00:27:42,720 --> 00:27:47,080
But like it, it was like a very 
nuanced reading of the rules 

492
00:27:47,080 --> 00:27:49,240
that just didn't capture the 
spirit of it at all. 

493
00:27:49,720 --> 00:27:55,880
So yeah, the thing that is super
interesting about prediction 

494
00:27:55,880 --> 00:27:59,360
markets, if we go back to call 
them financial contracts, 

495
00:27:59,520 --> 00:28:02,520
they're financial contracts, but
they're binary. 

496
00:28:02,600 --> 00:28:06,760
One side wins 100%, the other 
side loses everything. 

497
00:28:08,280 --> 00:28:12,080
And what that means is that if 
there's ambiguity in the rules, 

498
00:28:12,480 --> 00:28:16,000
the losing side has a really, 
really, really big incentive to 

499
00:28:16,000 --> 00:28:22,400
try to be loud and proud and try
to scream as as loudly as they 

500
00:28:22,400 --> 00:28:24,840
possibly can. 
Hey, hey, we're right, the other

501
00:28:24,840 --> 00:28:28,400
side's wrong. 
Or if they lose, they also have 

502
00:28:28,400 --> 00:28:31,920
an incentive to scream. 
The system is broken. 

503
00:28:32,800 --> 00:28:36,480
Scam manipulation, like all this
other kind of attacking stuff, 

504
00:28:36,680 --> 00:28:40,120
which, you know, sometimes I'm 
on the receiving end of, which 

505
00:28:40,120 --> 00:28:43,760
isn't particularly fun. 
But like the game theory here is

506
00:28:43,760 --> 00:28:47,000
like, look, if, if it's 
something with some ambiguity, 

507
00:28:47,160 --> 00:28:50,880
one side is going to be really 
upset because they're losing all

508
00:28:50,880 --> 00:28:54,040
their money. 
And that's human nature, right? 

509
00:28:54,760 --> 00:28:57,880
So what's my take on this? 
My take on this is that it's 

510
00:28:57,880 --> 00:29:00,040
tricky. 
And like you, Polymarket has a 

511
00:29:00,040 --> 00:29:02,840
process now of issuing 
clarifications around markets, 

512
00:29:03,640 --> 00:29:05,720
which are also sometimes very 
imperfect. 

513
00:29:06,000 --> 00:29:08,720
And you know, they don't ever 
want to be the one just like 

514
00:29:09,240 --> 00:29:11,480
deciding the market outcome here
too. 

515
00:29:12,440 --> 00:29:15,880
But I think we really try to use
the showing point concept to 

516
00:29:15,880 --> 00:29:20,360
come to the least wrong answer 
is the way I look at it. 

517
00:29:20,480 --> 00:29:25,120
Like what is the least wrong 
answer that we can offer to to 

518
00:29:25,120 --> 00:29:27,760
resolve these markets? 
Because you also touched on 

519
00:29:27,760 --> 00:29:31,560
another point that is very 
nuanced and not many people know

520
00:29:31,560 --> 00:29:34,600
of or think about. 
But if you go back to Auger 

521
00:29:34,600 --> 00:29:39,240
days, Auger had a lot of invalid
market outcomes. 

522
00:29:39,480 --> 00:29:42,320
So it just said this market 
isn't clear enough, we're just 

523
00:29:42,320 --> 00:29:48,240
going to not respond. 
And Uma and Pauli market 

524
00:29:48,240 --> 00:29:52,880
generally don't do that. 
We also a. 

525
00:29:53,400 --> 00:29:57,120
Terrible user experience, right?
So kind of yeah, yeah. 

526
00:29:57,240 --> 00:29:59,280
Because it's a terrible user 
experience. 

527
00:29:59,360 --> 00:30:01,520
Exactly right. 
You're like, hey, I'm a 

528
00:30:01,520 --> 00:30:03,360
prediction market trying to 
predict the future. 

529
00:30:03,480 --> 00:30:06,520
And then you're like, you kind 
of like can't, can't answer it 

530
00:30:06,640 --> 00:30:08,320
right. 
That's not good. 

531
00:30:09,520 --> 00:30:16,160
And so, but then that that said,
that forces the Oracle system to

532
00:30:16,160 --> 00:30:19,840
resolve slightly ambiguous 
outcomes too. 

533
00:30:20,640 --> 00:30:24,520
Yeah. 
Can you give us an idea of how 

534
00:30:24,520 --> 00:30:30,040
often disputes happen, kind of 
in absolute and relative terms? 

535
00:30:31,880 --> 00:30:36,520
Yeah, the dispute rate is less 
than 1% of all proposals. 

536
00:30:38,240 --> 00:30:40,920
We're actually putting a lot of 
effort into getting it down 

537
00:30:41,360 --> 00:30:47,400
more, and there's like a very 
cool project we're working on 

538
00:30:47,440 --> 00:30:51,080
that's not far away that I think
can actually lower it by an 

539
00:30:51,080 --> 00:30:56,760
order of magnitude. 
Too many of the disputes, like 

540
00:30:57,440 --> 00:31:00,440
I, I need to double check this, 
but it's something like 70% of 

541
00:31:00,440 --> 00:31:03,400
the disputes are actually from 
people proposing too early. 

542
00:31:03,720 --> 00:31:07,320
So they actually put the market 
up at before they should, which 

543
00:31:07,320 --> 00:31:10,120
is fascinating. 
And yeah, it's really 

544
00:31:10,120 --> 00:31:12,360
fascinating too that that 
happens. 

545
00:31:12,960 --> 00:31:18,040
So you can say that it's 
something like .3% of all 

546
00:31:18,160 --> 00:31:21,800
proposals are like legitimately 
disputed that aren't like too 

547
00:31:21,800 --> 00:31:27,920
early, something like that. 
And the the system is currently 

548
00:31:27,920 --> 00:31:32,880
processing between 250 and 500 
proposals a day like market 

549
00:31:32,880 --> 00:31:36,160
resolutions a day, which is up a
lot from six months ago. 

550
00:31:36,960 --> 00:31:42,760
Give us an idea of kind of who 
uses Uma's Arca, Yeah. 

551
00:31:43,440 --> 00:31:49,680
So the biggest user by number of
proposals by far is Polymarket. 

552
00:31:50,240 --> 00:31:54,680
They just, they're, yeah, 
they've kind of achieved escape 

553
00:31:54,680 --> 00:31:56,840
velocity in the prediction 
market space here. 

554
00:31:58,560 --> 00:32:01,040
Across, we'll talk about that 
maybe transition soon. 

555
00:32:01,320 --> 00:32:06,360
Across uses it also to validate 
this like complex data 

556
00:32:06,360 --> 00:32:08,120
structure. 
So it's a very different use 

557
00:32:08,120 --> 00:32:09,320
case. 
We're basically being like, 

558
00:32:09,520 --> 00:32:11,800
here's this complex data 
structure that anybody can 

559
00:32:11,800 --> 00:32:15,360
recreate, but it would be hard 
to do on chain. 

560
00:32:15,520 --> 00:32:17,560
Anyone can do it off chain 
easily though. 

561
00:32:18,480 --> 00:32:22,400
And Across uses Zuma to validate
whether that data structure was 

562
00:32:22,400 --> 00:32:26,120
created correctly or not. 
And then we have other like 

563
00:32:26,160 --> 00:32:29,120
interesting use cases that are 
experimenting like story 

564
00:32:29,120 --> 00:32:36,040
protocol, they're kind of doing 
IPIP stuff and they use the 

565
00:32:36,040 --> 00:32:38,960
system to resolve some IP 
disputes. 

566
00:32:39,400 --> 00:32:42,560
That's just getting going. 
And then there's a like a long 

567
00:32:42,560 --> 00:32:46,680
tail of smaller prediction 
market adjacent use cases too. 

568
00:32:47,600 --> 00:32:49,640
Super interesting. 
Maybe before we kind of 

569
00:32:49,640 --> 00:32:55,000
transition over to across what 
what talking about kind of like 

570
00:32:55,000 --> 00:32:58,040
the optimistic security 
assumptions, where would you say

571
00:32:58,040 --> 00:33:01,040
they work well and where do you 
think kind of like maybe they're

572
00:33:01,040 --> 00:33:02,600
not fragile, but we can do 
better? 

573
00:33:05,160 --> 00:33:11,120
I think they work well in 
markets where there are lots of 

574
00:33:11,160 --> 00:33:16,480
eyes on them, and eyes could be 
humans or machines too. 

575
00:33:16,480 --> 00:33:17,840
We'll come back to that in a 
second. 

576
00:33:19,640 --> 00:33:26,800
They also work well where like 
false outcomes are very obvious,

577
00:33:27,160 --> 00:33:29,600
right? 
So if we go back to the Trump 

578
00:33:29,600 --> 00:33:33,360
Harris election, there were a 
ton of eyes on that market and 

579
00:33:33,360 --> 00:33:35,600
the outcome is actually pretty 
obvious. 

580
00:33:35,840 --> 00:33:39,120
Maybe it's not obvious to 
resolve it like right in real 

581
00:33:39,120 --> 00:33:41,960
time, but it's obvious. 
Like if you if you, if you say 

582
00:33:42,040 --> 00:33:45,120
this is too early or I shouldn't
do this yet and you wait till 

583
00:33:45,120 --> 00:33:48,880
there's like enough pulling 
clarity, it's pretty obvious, 

584
00:33:49,000 --> 00:33:54,120
right, what the outcome is. 
So in those use cases, I think 

585
00:33:54,120 --> 00:33:58,200
these optimistic systems work 
really, really well where things

586
00:33:58,200 --> 00:34:02,200
get scary, right? 
It would be like, OK, there's so

587
00:34:02,200 --> 00:34:03,760
many markets. 
This goes back to kind of your 

588
00:34:03,760 --> 00:34:06,560
griefing example. 
There's so many markets or they 

589
00:34:06,560 --> 00:34:10,080
have small enough value in them 
or for whatever reason, there's 

590
00:34:10,080 --> 00:34:11,520
not enough eyeballs watching 
them. 

591
00:34:11,760 --> 00:34:15,199
Then I think there's like a 
legitimate question about like, 

592
00:34:15,199 --> 00:34:18,280
wait, is there anybody around to
dispute this if somebody does 

593
00:34:18,280 --> 00:34:19,840
try to sneak a battle come 
through? 

594
00:34:21,880 --> 00:34:26,480
However, this is where all of 
like the Super intelligences 

595
00:34:26,480 --> 00:34:30,560
that people are working on 
become extremely useful and you 

596
00:34:30,560 --> 00:34:36,239
think about what an LLM can do. 
I don't think it completely 

597
00:34:36,239 --> 00:34:42,600
replaces humans yet, but it 
certainly gives us a machine to 

598
00:34:42,600 --> 00:34:47,320
put a lot more eyeballs on a lot
of things, and I think that that

599
00:34:47,600 --> 00:34:51,800
actually strengthens many of the
optimistic verification 

600
00:34:51,800 --> 00:34:54,239
assumptions in an extremely 
useful way. 

601
00:34:56,480 --> 00:34:59,880
Yeah, I think that's that's a, 
that's a fantastic answer. 

602
00:35:00,480 --> 00:35:03,560
So you guys, you already talked 
about this briefly in the 

603
00:35:03,560 --> 00:35:06,800
beginning. 
So you guys actually started the

604
00:35:06,800 --> 00:35:11,600
bridge kind of initially kind of
like as a consumer of Uma, the 

605
00:35:11,600 --> 00:35:17,880
Oracle, how maybe kind of like 
the, the, the housekeeping 

606
00:35:17,880 --> 00:35:20,640
first, how did this work in 
terms of ownership structure? 

607
00:35:20,640 --> 00:35:22,960
So kind of these are two token 
projects. 

608
00:35:22,960 --> 00:35:26,400
So kind of like how, how, how 
are the tokens related? 

609
00:35:26,400 --> 00:35:31,480
And kind of like how, how did 
your first set of token holders 

610
00:35:31,520 --> 00:35:35,480
feel about kind of you guys 
working on a second token 

611
00:35:35,480 --> 00:35:37,920
project? 
I mean, I'm very much asking 

612
00:35:37,920 --> 00:35:40,600
kind of not for a friend. 
So kind of we've done this 

613
00:35:40,600 --> 00:35:45,040
before too, so. 
We looked at you guys for some 

614
00:35:45,040 --> 00:35:49,040
of this stuff a little bit too 
and it was it was interesting. 

615
00:35:49,040 --> 00:35:57,120
So that's so the way we looked 
at it is UMA users were like are

616
00:35:57,120 --> 00:36:02,760
happy to have other users of UMA
and at least at the time when we

617
00:36:02,760 --> 00:36:04,320
did this, it's like, OK, that 
makes sense. 

618
00:36:06,080 --> 00:36:09,040
And then we made an attempt to 
launch the across token in a 

619
00:36:09,040 --> 00:36:12,400
very fairway. 
And there's lots of actually 

620
00:36:12,520 --> 00:36:19,760
like lots of really interesting 
decisions that with more like 

621
00:36:19,960 --> 00:36:22,400
looking at them in hindsight, 
maybe could have done things 

622
00:36:22,400 --> 00:36:27,360
differently too. 
We, we in, in some ways I feel 

623
00:36:27,360 --> 00:36:31,360
like the across token was rushed
out because we actually needed, 

624
00:36:31,960 --> 00:36:37,840
we needed a token to gather some
LP funds to help make the bridge

625
00:36:37,840 --> 00:36:39,760
usable. 
Like we needed token emissions 

626
00:36:39,760 --> 00:36:43,600
to incentivize people to deposit
into our protocol. 

627
00:36:43,880 --> 00:36:46,920
And we actually came, put this 
out just a little bit before 

628
00:36:46,920 --> 00:36:50,200
people sort of started doing the
points thing, like the points 

629
00:36:50,200 --> 00:36:53,280
program thing. 
And it's funny because I think 

630
00:36:53,800 --> 00:36:56,200
first of all, I wish we invented
that idea, which we didn't. 

631
00:36:57,000 --> 00:37:01,000
But if we had the points idea, 
we may have delayed the token 

632
00:37:01,680 --> 00:37:04,880
much longer and used points to 
help incentivize some of the 

633
00:37:04,880 --> 00:37:09,120
behavior we needed. 
Anyways, neither here nor there.

634
00:37:09,240 --> 00:37:11,680
We did try to put the token out 
in a very fairway. 

635
00:37:12,160 --> 00:37:17,000
We tried to have a fairly broad 
AirDrop and the like. 

636
00:37:17,400 --> 00:37:21,400
The kind of UMA team actually 
had Pretty Little ownership in 

637
00:37:21,400 --> 00:37:24,120
the across token, at least early
on too. 

638
00:37:25,480 --> 00:37:26,840
And so nobody really had a 
problem with that. 

639
00:37:27,080 --> 00:37:28,320
That's the way I I'd answer 
that. 

640
00:37:28,760 --> 00:37:31,880
Yeah, it's just kind of like 
we're building cool stuff in the

641
00:37:31,880 --> 00:37:33,040
space. 
It's related. 

642
00:37:33,040 --> 00:37:35,160
It's good for both projects. 
It's good for both teams. 

643
00:37:35,240 --> 00:37:40,240
That's good. 
So maybe let's talk about how 

644
00:37:40,360 --> 00:37:44,720
across used to work. 
So across used to use, you know,

645
00:37:44,720 --> 00:37:48,280
a purely optimistic model. 
Let's talk about this first and 

646
00:37:48,280 --> 00:37:51,560
then kind of like how you've 
recently kind of upgraded it in 

647
00:37:51,560 --> 00:37:55,040
the ZK RAM. 
Yeah, so you know, your listener

648
00:37:55,040 --> 00:37:58,560
base is pretty nerdy. 
We'll take. 

649
00:37:58,920 --> 00:38:01,800
That as a compliment. 
A a massive compliment. 

650
00:38:02,440 --> 00:38:05,760
You know, they're not the not 
the crypto curious folk that 

651
00:38:05,760 --> 00:38:08,520
like are are we can go deep on 
this stuff. 

652
00:38:08,520 --> 00:38:13,320
So what does a cross do? 
Let's actually start there, if 

653
00:38:13,320 --> 00:38:15,040
that's OK. 
So a cross is an intent based 

654
00:38:15,040 --> 00:38:18,120
bridge. 
The way I, I explain this, and 

655
00:38:18,120 --> 00:38:20,520
this is this is the basic 
explanation, but I want it for 

656
00:38:20,520 --> 00:38:23,000
blockchain A to blockchain B. 
We'll make it arbitrary to base.

657
00:38:23,680 --> 00:38:27,720
How can I do that? 
The naive way is I deposit 

658
00:38:27,720 --> 00:38:33,240
something on Arbitrum, I send a 
message to base, and then I 

659
00:38:33,240 --> 00:38:37,520
release funds on base to the 
user and that's all well and 

660
00:38:37,520 --> 00:38:39,640
good. 
That's how I, I think a lot of 

661
00:38:39,640 --> 00:38:41,280
like first generation bridges 
work. 

662
00:38:42,560 --> 00:38:46,560
And the problem with that is I 
need to wait for finality or a 

663
00:38:46,920 --> 00:38:50,680
high degree of finality on 
blockchain A before I send that 

664
00:38:50,680 --> 00:38:52,880
message. 
Cuz if that message is wrong, 

665
00:38:52,880 --> 00:38:56,320
I'm gonna like release funds 
from a pool or something or mint

666
00:38:56,760 --> 00:39:00,280
tokens that aren't backed if 
there's a reorg on A. 

667
00:39:00,280 --> 00:39:02,920
So I have to wait for finality 
and then I have to send that 

668
00:39:02,920 --> 00:39:05,440
message and that's like a slow 
process. 

669
00:39:06,680 --> 00:39:11,000
So what a cross did is we're 
like our whole MO is we want 

670
00:39:11,000 --> 00:39:13,680
bridging to be a 2 second or 
less experience. 

671
00:39:13,680 --> 00:39:17,000
We want it to be fast and cheap,
but we think like this speed is 

672
00:39:17,000 --> 00:39:20,560
critically important. 
So we're like, OK, well, we have

673
00:39:20,560 --> 00:39:24,640
finality constraints on the 
origin chain that just are not 

674
00:39:24,640 --> 00:39:28,360
going to let us do stuff in 2 
seconds with at least with like 

675
00:39:28,360 --> 00:39:33,880
other people's money. 
However, we could introduce 1/3 

676
00:39:33,880 --> 00:39:40,480
actor, a solver, or a relayer, 
same term that is sophisticated 

677
00:39:40,480 --> 00:39:43,880
enough to price the reorg risk 
or understand the risks they're 

678
00:39:43,880 --> 00:39:48,040
taking, and we could use them to
front money to the user on the 

679
00:39:48,040 --> 00:39:51,600
destination chain very quickly 
and then they get packed. 

680
00:39:51,840 --> 00:39:54,760
They get paid back later after 
we verify the fill habit. 

681
00:39:55,520 --> 00:39:59,400
So this is the intent based 
model where a user effectively 

682
00:39:59,640 --> 00:40:02,840
deposits on chain A, they 
deposit into escrow, A race 

683
00:40:02,840 --> 00:40:06,280
starts for the third party 
solver to fill them on chain B, 

684
00:40:06,440 --> 00:40:08,560
Third party solver fills them on
chain B very quickly. 

685
00:40:09,560 --> 00:40:13,120
And then user goes on with their
day, they're happy, and then the

686
00:40:13,120 --> 00:40:16,560
protocol says verifies that fill
happened before releasing the 

687
00:40:16,560 --> 00:40:18,920
funds back to the solver. 
Yeah. 

688
00:40:18,920 --> 00:40:21,120
I mean, it's a slightly 
different design than many 

689
00:40:21,120 --> 00:40:24,480
optimistic bridges where kind of
you say, OK, look, you kind of 

690
00:40:24,480 --> 00:40:28,320
you, you kind of you bridge 
optimistically and there's kind 

691
00:40:28,320 --> 00:40:31,520
of there's a message sent across
that bridge. 

692
00:40:32,160 --> 00:40:35,000
And then kind of on the other 
side, kind of like you kind of 

693
00:40:35,200 --> 00:40:39,920
you, you someone, someone kind 
of fronts you the liquidity to 

694
00:40:39,920 --> 00:40:44,080
kind of already use the funds on
the destination chain for a 

695
00:40:44,080 --> 00:40:49,160
couple of basis points until 
kind of the optimistic time the 

696
00:40:49,160 --> 00:40:51,240
time period has has run out, 
right. 

697
00:40:51,240 --> 00:40:54,240
So kind of how, how would you 
kind of pit these against one 

698
00:40:54,240 --> 00:40:58,400
another? 
I mean the there's no optimistic

699
00:40:58,600 --> 00:41:00,760
part in what I just described. 
We can go and maybe the 

700
00:41:00,760 --> 00:41:03,920
verification of this, but the 
fact is user wants funds 

701
00:41:03,920 --> 00:41:05,800
unencumbered on the destination 
chain. 

702
00:41:06,480 --> 00:41:09,960
So we just use the third party 
solver to just give them their 

703
00:41:10,160 --> 00:41:12,600
like give them money and the 
user goes and they have the 

704
00:41:12,600 --> 00:41:13,920
money and they can do whatever 
they want. 

705
00:41:13,920 --> 00:41:15,800
And there's no chance of like a 
rollback. 

706
00:41:15,800 --> 00:41:17,640
They just, they have the funds, 
right? 

707
00:41:18,720 --> 00:41:21,760
So it's very clear, like there's
nothing weird going on there. 

708
00:41:22,360 --> 00:41:26,080
And the solver just has some 
risk that if there's a reorg on 

709
00:41:26,080 --> 00:41:29,440
chain A, there's some risk of 
ruin that they like lose their 

710
00:41:29,440 --> 00:41:31,000
funds or something like that 
too. 

711
00:41:31,320 --> 00:41:34,600
But they're very good at pricing
this and we use market forces to

712
00:41:34,600 --> 00:41:37,920
price this reorg risk all over 
the place. 

713
00:41:37,920 --> 00:41:41,400
And so it really does allow us 
to have two second bridge 

714
00:41:41,400 --> 00:41:45,480
experiences between all the 
major L twos with like very, 

715
00:41:45,880 --> 00:41:48,520
pretty low fees, very low. 
Fees, can anyone be a solver? 

716
00:41:48,520 --> 00:41:53,000
So kind of like, say, for 
instance, I, I had dirty funds 

717
00:41:53,000 --> 00:41:56,280
that kind of like I wanted to 
distribute amongst kind of like 

718
00:41:56,800 --> 00:41:59,520
innocent people, kind of say 
from some sort of hack. 

719
00:42:00,000 --> 00:42:03,440
Could I just kind of like send 
this to, to, to, to people on 

720
00:42:03,440 --> 00:42:06,920
the destination chain and kind 
of reclaim the, the, the clean 

721
00:42:06,920 --> 00:42:08,720
fund that they initially 
deposited? 

722
00:42:09,280 --> 00:42:11,880
Man, you're asking me like the 
hard questions here. 

723
00:42:12,640 --> 00:42:18,320
Solving is permissionless with 
like asterisks and caveats. 

724
00:42:19,560 --> 00:42:25,480
We have not had any rogue or 
like any dirty solvers 

725
00:42:25,480 --> 00:42:29,640
participate in our network and 
we do have ways to prevent them 

726
00:42:29,640 --> 00:42:32,840
from participating in our 
network while still maintaining 

727
00:42:32,840 --> 00:42:35,960
the permissionless ethos. 
I don't know that I actually 

728
00:42:35,960 --> 00:42:39,760
want to share all the ways that 
we have to prevent them for for 

729
00:42:39,800 --> 00:42:45,280
reasons, but it's it's a very 
good question that we've 

730
00:42:45,280 --> 00:42:49,920
actually gone pretty deep on. 
It's, it's, there's also not a, 

731
00:42:49,920 --> 00:42:54,680
it's not a very good mechanism 
to wash funds either. 

732
00:42:54,680 --> 00:43:00,480
Like it's all pretty, you have 
to compete against our other 

733
00:43:00,480 --> 00:43:03,680
solvers that are very 
competitive too and win. 

734
00:43:03,920 --> 00:43:08,680
So it's it would actually 
require a lot, a lot a lot of 

735
00:43:08,680 --> 00:43:12,320
expertise to do this at any type
of scale too. 

736
00:43:13,480 --> 00:43:15,680
But no. 
That's all laundering, kind of 

737
00:43:15,680 --> 00:43:19,400
like laundering is, is an 
incredibly labour intensive 

738
00:43:19,400 --> 00:43:21,400
business, right? 
Kind of like This is why Lazarus

739
00:43:21,400 --> 00:43:23,160
has like 20,000 people doing 
this. 

740
00:43:24,000 --> 00:43:27,680
Is it 20,000 now? 
Well it's 25,000 in total, but 

741
00:43:27,680 --> 00:43:31,040
kind of like a majority of them 
are are supposedly doing 

742
00:43:31,040 --> 00:43:33,640
laundering so. 
Yeah, Yeah. 

743
00:43:33,760 --> 00:43:38,000
OK. 
Well, for our friends out there,

744
00:43:38,000 --> 00:43:40,920
I'm not going to share how we 
can prevent this, but we can 

745
00:43:40,920 --> 00:43:44,880
prevent it I think in a pretty 
in a fairly robust way while 

746
00:43:44,880 --> 00:43:48,680
also securing the ethos of 
permissionless participation in 

747
00:43:48,680 --> 00:43:51,560
our network. 
And we haven't seen any evidence

748
00:43:51,560 --> 00:43:53,120
of this today. 
OK. 

749
00:43:53,600 --> 00:43:57,000
How does the pricing work? 
So kind of like I'm, I'm, I 

750
00:43:57,000 --> 00:43:59,480
mean, I kind of there's lots of 
things that kind of I have to 

751
00:43:59,480 --> 00:44:02,240
factor in. 
So kind of like how how often 

752
00:44:02,240 --> 00:44:04,960
can I use my funds one way or 
the other? 

753
00:44:04,960 --> 00:44:07,680
Kind of like is there a 
preferred way of bridging? 

754
00:44:07,800 --> 00:44:11,240
Kind of do I have to kind of 
route them kind of back the long

755
00:44:11,240 --> 00:44:14,920
way or kind of like, yeah, so 
kind of all of these things. 

756
00:44:14,920 --> 00:44:17,880
So kind of, I assume kind of 
every solver kind of does this 

757
00:44:18,080 --> 00:44:24,960
kind of like on on their end. 
But do you have any any idea of 

758
00:44:24,960 --> 00:44:27,640
kind of like what goes into this
pricing mechanism? 

759
00:44:28,360 --> 00:44:34,360
Yeah, I have a lot and it's 
super nerdy and super fun, but 

760
00:44:34,600 --> 00:44:37,280
you can actually step back and 
be like, OK, so filling this 

761
00:44:37,280 --> 00:44:40,200
intent again, go back to our 
example from A to B, from 

762
00:44:40,200 --> 00:44:43,640
Arbitrum to base, filling this 
intent, we're actually kind of 

763
00:44:44,280 --> 00:44:48,280
competing on 2 dimensions, 
competing on price and competing

764
00:44:48,280 --> 00:44:50,040
on speed. 
Who can do it fastest. 

765
00:44:51,240 --> 00:44:55,080
And what we've chosen to do to 
date is actually just compete on

766
00:44:55,080 --> 00:44:58,520
speed. 
So our API, you know, you can 

767
00:44:58,520 --> 00:45:00,240
set your own fee. 
It's permissionless that way. 

768
00:45:00,480 --> 00:45:04,360
But our API will tell most users
that use like our API or use our

769
00:45:04,360 --> 00:45:08,560
front end, we will suggest a fee
of what the the user should 

770
00:45:08,680 --> 00:45:11,440
submit. 
And then all the solvers are 

771
00:45:11,440 --> 00:45:14,680
purely competing to win that fee
on the destination chain 

772
00:45:14,680 --> 00:45:19,040
competing based on speed. 
And we've done this because we 

773
00:45:19,040 --> 00:45:21,360
really tried to sell the fast 
user experience. 

774
00:45:22,080 --> 00:45:25,720
And so we definitely in in many 
ways we charge well 

775
00:45:26,280 --> 00:45:28,440
definitionally we charge too 
much. 

776
00:45:28,440 --> 00:45:32,040
We charge more than the marginal
cost that like purely 

777
00:45:32,040 --> 00:45:35,160
competitive price of what it 
would take to fill on the 

778
00:45:35,160 --> 00:45:39,240
destination chain because we are
trying to have all the solvers 

779
00:45:39,240 --> 00:45:42,800
compete on speed and we've 
gotten our own heuristics to to 

780
00:45:42,880 --> 00:45:47,000
kind of set that price in a way 
that we think is going to lead 

781
00:45:47,000 --> 00:45:49,480
to good competition on the the 
fill. 

782
00:45:52,080 --> 00:45:54,680
There's a very, very cool idea 
that it's probably going to be a

783
00:45:54,680 --> 00:45:58,360
white paper there where we like 
can kind of do both that not 

784
00:45:58,360 --> 00:46:01,960
quite ready to talk about, but I
think there's very cool ways 

785
00:46:01,960 --> 00:46:06,680
that we can do both that are are
still have a good UX here too, 

786
00:46:07,480 --> 00:46:10,120
which I'm excited about. 
But yeah, that that's what we're

787
00:46:10,120 --> 00:46:12,640
doing today. 
And you know, setting that fee, 

788
00:46:12,840 --> 00:46:17,240
the fee is a matter of gas costs
on origin and destination chain.

789
00:46:17,520 --> 00:46:21,240
Our gas costs of our system are 
very lightweight because we 

790
00:46:21,240 --> 00:46:23,080
batch the verification which we 
have. 

791
00:46:23,160 --> 00:46:25,160
We can talk about the UMMA 
component here too. 

792
00:46:25,480 --> 00:46:29,240
So our gas costs are extremely 
lightweight both sides, but 

793
00:46:29,240 --> 00:46:32,680
there's still a gas cost. 
So that goes in part of the fee 

794
00:46:32,680 --> 00:46:35,640
estimate that goes into the fee 
estimation. 

795
00:46:36,080 --> 00:46:39,880
The other costs would be, OK, 
how long before we repay the 

796
00:46:39,880 --> 00:46:42,240
solver? 
So they're making a loan How 

797
00:46:42,240 --> 00:46:46,120
what's the cost of capital? 
How do we manage that? 

798
00:46:46,120 --> 00:46:52,320
Or the third cost would be 
rebalancing costs. 

799
00:46:52,480 --> 00:46:57,640
So user is solver has to front 
money on this chain. 

800
00:46:57,920 --> 00:47:03,240
How easy or cheap or how long 
does it take to rebalance funds 

801
00:47:03,240 --> 00:47:06,240
on and off of that chain, which 
is a very difficult thing to 

802
00:47:06,240 --> 00:47:07,960
measure, but you can kind of 
approximate it. 

803
00:47:09,120 --> 00:47:14,840
And then the 4th cost would be 
the 4th cost we actually get to 

804
00:47:14,840 --> 00:47:16,760
ignore. 
The 4th cost would be like, 

805
00:47:16,760 --> 00:47:21,160
what's the risk of a reorg on 
the origin chain, which would 

806
00:47:21,160 --> 00:47:22,960
cause the solver to not get 
repaid? 

807
00:47:23,960 --> 00:47:27,120
That actually gets priced into 
the speed competition. 

808
00:47:27,520 --> 00:47:31,360
So solvers can be like, OK, how 
many blocks of finality on the 

809
00:47:31,360 --> 00:47:35,640
origin chain do I need to see 
the users deposit transaction 

810
00:47:35,640 --> 00:47:39,840
into escrow before I feel 
confident that that the risk of 

811
00:47:39,840 --> 00:47:42,920
reorg is low enough for me to 
actually take this risk on. 

812
00:47:43,200 --> 00:47:47,880
So that's that one kind of gets 
lumped into speed here. 

813
00:47:48,680 --> 00:47:51,000
And so we get to think that's 
pretty pretty deeply. 

814
00:47:51,000 --> 00:47:54,000
It's pretty fun. 
But that's that's the the nerdy 

815
00:47:54,000 --> 00:47:56,200
answer to your. 
That's kind of like a reverse 

816
00:47:56,200 --> 00:47:59,200
Dutch auction, but yeah. 
And you kind of you send the, 

817
00:47:59,480 --> 00:48:03,680
the you send the bid at the at 
the time point where you feel 

818
00:48:03,680 --> 00:48:07,040
like kind of the the cost kind 
of balance. 

819
00:48:07,880 --> 00:48:14,360
So you kind of recently switched
to AZK bridge for or AZK 

820
00:48:14,400 --> 00:48:19,160
verification mechanism for part 
of the bridge experience, namely

821
00:48:19,160 --> 00:48:21,480
to BSE, right? 
Correct. 

822
00:48:21,720 --> 00:48:26,880
So we've added ZKZK magic and it
really is magic. 

823
00:48:27,200 --> 00:48:32,600
We've added it to part of the 
cross intent verification, let's

824
00:48:32,600 --> 00:48:34,600
call it the settlement system 
here. 

825
00:48:35,560 --> 00:48:42,800
So I look at a cross and all 
intent systems in three layers. 

826
00:48:42,880 --> 00:48:45,160
There's like the auction layer 
of who's going to fill the 

827
00:48:45,160 --> 00:48:48,480
intent, there's the solver layer
of who's the solver that's 

828
00:48:48,480 --> 00:48:50,440
actually doing the work to fill 
the intent. 

829
00:48:50,800 --> 00:48:53,680
And there's the settlement layer
where funds go into escrow and 

830
00:48:53,680 --> 00:48:57,360
then we verify that the intent 
got filled before releasing 

831
00:48:57,360 --> 00:49:00,200
funds. 
So one thing that a cross does 

832
00:49:00,200 --> 00:49:04,640
that I think has been critically
important to us working well to 

833
00:49:04,640 --> 00:49:08,360
date is we don't verify each 
intent individually. 

834
00:49:09,760 --> 00:49:13,520
So this, the naive system would 
be like, OK, intent got filled. 

835
00:49:13,840 --> 00:49:16,640
I now need to send a message 
proving that the intent got 

836
00:49:16,640 --> 00:49:18,680
filled to release that users 
funds from escrow. 

837
00:49:19,280 --> 00:49:22,680
And that means I'm sending one 
message per transaction, per 

838
00:49:22,680 --> 00:49:26,280
bridge transaction, which you 
know, we're doing 50,000 plus 

839
00:49:26,280 --> 00:49:29,840
transactions a day. 
It's a lot of messages that are 

840
00:49:30,080 --> 00:49:32,560
costly. 
It's just a lot of stuff. 

841
00:49:34,280 --> 00:49:36,640
And so we've always taken the 
approach where it's like, well, 

842
00:49:37,440 --> 00:49:38,880
and you also have to send the 
message. 

843
00:49:38,880 --> 00:49:42,480
It's pair wise, right? 
So if I support N chains, I have

844
00:49:42,480 --> 00:49:45,480
n ^2 routes and so I have to 
send messages in all these 

845
00:49:45,480 --> 00:49:48,360
directions and it's it's, it's 
kind of a mess. 

846
00:49:49,600 --> 00:49:51,600
So we've always had the approach
that we're like, actually we're 

847
00:49:51,600 --> 00:49:57,640
better off batching all of the 
verifications into a period in 

848
00:49:57,680 --> 00:49:59,800
epoch and we make it about an 
hour. 

849
00:50:00,040 --> 00:50:03,440
So we say, OK, for every hour, 
we're going to look at all the 

850
00:50:03,440 --> 00:50:06,440
fills across all the chains. 
And we're going to create this 

851
00:50:06,440 --> 00:50:09,760
data structure, we call it a 
bundle that says here's all the 

852
00:50:09,760 --> 00:50:11,360
fills that happened at all the 
chains. 

853
00:50:11,560 --> 00:50:14,160
We sum them up. 
If you're a solver that did like

854
00:50:14,160 --> 00:50:17,360
10 fills on one route, we say 
we're going to pay you once for 

855
00:50:17,360 --> 00:50:20,000
back for all these fills, which 
also reduces gas costs. 

856
00:50:20,640 --> 00:50:24,640
Do all this stuff and then we 
take this bundle, we 

857
00:50:24,680 --> 00:50:27,720
optimistically verify it using 
UMA on main net. 

858
00:50:28,920 --> 00:50:34,640
And then once that bundle is is 
is been not challenged past the 

859
00:50:34,640 --> 00:50:38,600
challenge window, we then use 
the canonical message bridges to

860
00:50:38,600 --> 00:50:42,240
send it to all the L twos to a 
contract that will release funds

861
00:50:42,640 --> 00:50:44,600
if there are funds to be 
released to All's chance. 

862
00:50:44,760 --> 00:50:46,560
So it was like a long process I 
just walked through. 

863
00:50:46,760 --> 00:50:49,520
But yeah, we're basically doing 
batching and we're 

864
00:50:49,520 --> 00:50:51,800
optimistically verifying this 
batch and they're using the 

865
00:50:51,800 --> 00:50:54,400
canonical bridges to send that 
bundle to all the chance. 

866
00:50:55,440 --> 00:50:58,160
That makes a lot of sense. 
Let me just quickly kind of 

867
00:50:58,800 --> 00:51:03,440
interject here kind of the 
people who kind of verify this 

868
00:51:03,440 --> 00:51:09,000
on the UMA network. 
So the people they are in 

869
00:51:09,000 --> 00:51:12,760
principle the same crowd kind of
also you go to for Poly market 

870
00:51:12,760 --> 00:51:16,920
statements and so on. 
So kind of how kind of verifying

871
00:51:16,920 --> 00:51:20,560
a data structure and kind of 
saying whether who was elected 

872
00:51:20,560 --> 00:51:23,000
president are two very different
skill sets. 

873
00:51:23,200 --> 00:51:27,320
And I think kind of like not, 
not kind of one is much more 

874
00:51:27,320 --> 00:51:30,000
vanilla than the other, right. 
So kind of like how do you scale

875
00:51:30,000 --> 00:51:35,000
up your your validators to kind 
of to kind of, yeah. 

876
00:51:35,680 --> 00:51:39,600
Well, there's two, I think there
you're sort of skipping one step

877
00:51:39,600 --> 00:51:43,720
here because there's there's the
disputer in the cross system. 

878
00:51:44,120 --> 00:51:47,960
So the disputers actually 
naturally are solvers in our 

879
00:51:47,960 --> 00:51:53,000
system too, where they're like, 
wait, this bundle doesn't pay me

880
00:51:53,000 --> 00:51:56,400
back the money I'm owed, I'm 
going to dispute it, right? 

881
00:51:56,680 --> 00:52:00,000
So we actually have a natural 
set of sophisticated disputers 

882
00:52:00,240 --> 00:52:02,800
for the across system to be 
like, this bundle isn't right. 

883
00:52:03,960 --> 00:52:06,520
Once it's been disputed, then 
you're absolutely correct. 

884
00:52:06,720 --> 00:52:11,240
Then the same room of voters 
that are voting on, did Trump or

885
00:52:11,240 --> 00:52:15,200
Harris win the election are now 
voting on, was bundle A or 

886
00:52:15,200 --> 00:52:19,320
bundle B correct, right. 
Or rather they're voting on, was

887
00:52:19,320 --> 00:52:21,560
bundle A correct or did it miss 
something? 

888
00:52:22,640 --> 00:52:25,880
But they now have period, like 
time where it's like somebody 

889
00:52:25,880 --> 00:52:29,120
can go and be like, if you run 
this code, which you can go and 

890
00:52:29,120 --> 00:52:32,200
do yourself and you should go 
and do yourself, you can see 

891
00:52:32,200 --> 00:52:34,320
that this bundle was incorrect 
for this reason. 

892
00:52:34,640 --> 00:52:38,320
And so then the voters are kind 
of just able to capture that 

893
00:52:38,320 --> 00:52:41,400
part effectively. 
OK. 

894
00:52:41,400 --> 00:52:43,520
Does that make sense? 
Yeah, that makes sense. 

895
00:52:43,920 --> 00:52:46,240
Maybe let's talk about kind of 
like the wider bridging space, 

896
00:52:46,240 --> 00:52:48,800
OK. 
So kind of we see kind of. 

897
00:52:49,560 --> 00:52:50,960
Can I go back? 
Because we didn't talk about the

898
00:52:50,960 --> 00:52:54,440
ZK bit in Across yet and I want 
to make sure we, we, we get 

899
00:52:54,440 --> 00:52:57,400
that. 
So first step, if you go back to

900
00:52:57,400 --> 00:52:59,760
our design where we're doing 
this batching optimistically 

901
00:52:59,760 --> 00:53:02,400
verifying this bundle. 
And then because we actually had

902
00:53:02,400 --> 00:53:05,520
this belief where we didn't want
to add in additional third party

903
00:53:05,520 --> 00:53:09,760
trust assumptions, we were using
the canonical bridges to send 

904
00:53:09,760 --> 00:53:13,560
this bundle to all the chains. 
So a requirement in the across 

905
00:53:13,560 --> 00:53:17,920
system before ZK was that you 
had a canonical message bridge 

906
00:53:18,120 --> 00:53:22,160
that could connect to Aetherium 
L1 and there are chains that 

907
00:53:22,160 --> 00:53:24,880
don't have that and they're 
growing, right. 

908
00:53:25,240 --> 00:53:31,080
So what we've done with Succinct
is we've created a ZK proof of 

909
00:53:31,080 --> 00:53:36,920
that bundle and then we're able 
to take that ZK proof and bring 

910
00:53:36,920 --> 00:53:40,400
it to any chain include like 
including chains that aren't 

911
00:53:40,400 --> 00:53:44,040
connected to Aetherium mainnet 
like Binance Smart Chain. 

912
00:53:44,360 --> 00:53:48,400
And we can then verify fills in 
like they had a canonical 

913
00:53:48,400 --> 00:53:49,960
message bridge going to that 
chain. 

914
00:53:51,120 --> 00:53:56,120
So we're able to use ZK to 
basically delete the need to 

915
00:53:56,120 --> 00:54:00,120
have a canonical message bridge 
between Ethereum L1 and the L2. 

916
00:54:00,640 --> 00:54:05,880
And this has advantages also for
L twos that do have canonical 

917
00:54:05,880 --> 00:54:07,880
message bridges because they're 
different. 

918
00:54:08,000 --> 00:54:10,440
We actually take this 
engineering work and like smart 

919
00:54:10,440 --> 00:54:14,120
contract audits to add new L 
twos because their message 

920
00:54:14,120 --> 00:54:18,240
bridge might look different, 
whereas the ZK proof is the same

921
00:54:18,240 --> 00:54:21,920
on every chain. 
So our new process is batch 

922
00:54:21,920 --> 00:54:26,560
verify, sort of create, batch, 
batch these intents, verify them

923
00:54:26,560 --> 00:54:29,160
optimistically, create AZK 
proof, and then send that to all

924
00:54:29,160 --> 00:54:33,920
the chains. 
You can't imagine that we might 

925
00:54:33,920 --> 00:54:36,840
be able to do more ZK stuff. 
Hint hint. 

926
00:54:36,920 --> 00:54:41,000
Like we might be able to do more
ZK stuff that lets us like 

927
00:54:41,000 --> 00:54:46,800
further compress that process 
and get to get to more chains 

928
00:54:46,800 --> 00:54:51,800
faster too Cool. 
Yeah, I know that that 

929
00:54:51,800 --> 00:54:56,440
definitely makes a lot of sense.
How do you see kind of the 

930
00:54:56,440 --> 00:54:58,120
fragmentation in the bridging 
space? 

931
00:54:58,120 --> 00:55:02,640
So do do you think kind of we're
converged towards one dominant 

932
00:55:02,640 --> 00:55:06,200
model or do you think kind of 
we'll retain kind of this 

933
00:55:07,600 --> 00:55:13,440
baconized state? 
There's an incredible amount of 

934
00:55:13,440 --> 00:55:17,200
nuance in that question. 
But again, you have a nerdy 

935
00:55:17,200 --> 00:55:19,800
listener base, so we can we can 
touch on it, right? 

936
00:55:21,280 --> 00:55:26,160
Bridging is bridging is like an 
overloaded word that means a 

937
00:55:26,160 --> 00:55:31,560
bunch of things here. 
There are many bridges that are 

938
00:55:32,240 --> 00:55:35,200
mint and burn bridges for 
specific tokens. 

939
00:55:36,200 --> 00:55:40,800
Example circles USDC, they have 
their own mint and burn bridge 

940
00:55:40,800 --> 00:55:46,240
called CCTP Circle Cross Chain 
Transfer Protocol that lets you 

941
00:55:46,480 --> 00:55:50,400
burn USDC on one chain and mint 
and on another, right? 

942
00:55:51,720 --> 00:55:54,200
So it's a form of bridge, but 
it's quite different from what 

943
00:55:54,200 --> 00:55:58,000
we do. 
It's meant to be like really 

944
00:55:58,000 --> 00:56:00,800
secure and they take 20 minutes 
coming from a theory and stuff 

945
00:56:00,800 --> 00:56:04,840
like that because circle does 
not want to just mint, you know,

946
00:56:04,840 --> 00:56:07,520
$10 million on some chain by 
mistake, right. 

947
00:56:07,520 --> 00:56:09,000
That would they would lose their
own money. 

948
00:56:09,480 --> 00:56:12,800
OK. 
And then you've got layer zero 

949
00:56:12,800 --> 00:56:15,400
with OF TS. 
So they're using OF TS to do 

950
00:56:15,400 --> 00:56:19,200
something similar with their own
set of security assumptions, 

951
00:56:19,200 --> 00:56:21,600
with their own set of 
validators. 

952
00:56:22,040 --> 00:56:26,600
You have wormhole doing NT TS, 
same deal using wormhole 

953
00:56:26,600 --> 00:56:28,880
validators. 
But these are not the bridges 

954
00:56:28,880 --> 00:56:31,760
that look like what we're doing.
These are like allowing you to 

955
00:56:31,760 --> 00:56:34,120
mint and burn a specific token 
on different chants. 

956
00:56:34,520 --> 00:56:37,600
And that to me feels very 
fragmented. 

957
00:56:37,920 --> 00:56:41,760
And that's not the business it 
crosses in at all, nor the 

958
00:56:41,760 --> 00:56:45,480
business we're going to enter. 
And I do feel like there is 

959
00:56:45,480 --> 00:56:48,120
going to be fragmentation there 
for a long time. 

960
00:56:48,280 --> 00:56:51,440
There's going to be like many 
standard, many teams that are 

961
00:56:51,440 --> 00:56:55,320
warring for market share around 
minting and burning tokens here.

962
00:56:56,720 --> 00:57:01,960
That's one thing on the bridging
side, when I think about the 

963
00:57:01,960 --> 00:57:06,560
bridging architecture, I, I 
think intents are the clearly 

964
00:57:06,560 --> 00:57:10,840
the only way that Ethereum is 
going to feel united and broader

965
00:57:10,840 --> 00:57:12,720
crypto is going to feel united 
too. 

966
00:57:13,120 --> 00:57:15,320
And I do not think that means 
that like everybody uses a 

967
00:57:15,320 --> 00:57:17,480
cross. 
I don't think that that's right.

968
00:57:17,920 --> 00:57:22,680
But I think the intent, standard
intent concept is I think this 

969
00:57:22,680 --> 00:57:25,680
need for speed for having 
transact transactions take like 

970
00:57:25,680 --> 00:57:28,720
2 seconds or less. 
I think that is critical from 

971
00:57:28,720 --> 00:57:31,280
just a user experience in a 
multi chain world. 

972
00:57:33,160 --> 00:57:36,080
So we, we created a standard for
intense, we co-authored a 

973
00:57:36,080 --> 00:57:43,360
standard with Uniswap called ERC
7683 that defines a common 

974
00:57:43,360 --> 00:57:48,880
interface to express an intent. 
And we're doing this as a public

975
00:57:48,880 --> 00:57:51,680
good. 
So that many intent protocols 

976
00:57:51,680 --> 00:57:56,840
can adopt the same intent 
standard and solvers can listen 

977
00:57:56,840 --> 00:58:00,200
to the same intent format makes 
it less work for solvers to 

978
00:58:00,200 --> 00:58:04,280
support intent systems. 
And in doing so, we can kind of 

979
00:58:04,280 --> 00:58:10,800
like push this to 2nd or less 
user experience everywhere where

980
00:58:10,800 --> 00:58:13,960
a cross is meant to be a service
provider. 

981
00:58:13,960 --> 00:58:17,760
I hope to be the premier service
provider of Intense, but by no 

982
00:58:17,760 --> 00:58:20,880
means like the only one. 
Does that make sense? 

983
00:58:21,760 --> 00:58:23,960
It's a long answer. 
That makes sense. 

984
00:58:24,040 --> 00:58:26,960
Do you think bridging is 
something that in the future 

985
00:58:27,440 --> 00:58:32,520
mostly builders will have to 
worry about? 

986
00:58:32,520 --> 00:58:35,400
Do you think kind of this will 
be this experience will be 

987
00:58:35,520 --> 00:58:38,280
abstracted the way in the user 
experience layer? 

988
00:58:39,760 --> 00:58:43,800
Yes, although I thought that for
a couple years and it's been 

989
00:58:43,800 --> 00:58:50,320
actually pretty slow to happen. 
So we have for, you know, a 

990
00:58:50,320 --> 00:58:55,480
cross is integrated into 
Uniswap, which I think is kind 

991
00:58:55,480 --> 00:58:57,800
of cool. 
It's been a big integration for 

992
00:58:57,800 --> 00:59:02,960
us. 
And I we've sold the cross or 

993
00:59:02,960 --> 00:59:05,880
we've attempted to sort of talk 
to a bunch of Daps that should 

994
00:59:05,880 --> 00:59:08,560
integrate across into their 
products too. 

995
00:59:10,000 --> 00:59:12,120
And we've had some traction and 
some interest. 

996
00:59:12,360 --> 00:59:15,320
But when we look at our volume 
and where it's coming from, the 

997
00:59:15,320 --> 00:59:19,200
majority of volume still comes 
from front ends or aggregators, 

998
00:59:19,200 --> 00:59:23,240
places where users go and they 
say I want to bridge and they 

999
00:59:23,240 --> 00:59:27,160
specifically are going to like 
the across .2 front end to 

1000
00:59:27,160 --> 00:59:32,720
bridge from chain A to chain B. 
And it's been slower than I 

1001
00:59:32,720 --> 00:59:38,440
expected for that process to get
integrated and abstracted into 

1002
00:59:38,440 --> 00:59:43,800
Daps that builders do. 
And I don't actually think I 

1003
00:59:44,040 --> 00:59:50,040
totally know why yet. 
My working theories are crypto 

1004
00:59:50,040 --> 00:59:53,560
is still got a bunch of D Jens 
that actually like doing 

1005
00:59:53,560 --> 00:59:56,880
bridging manually. 
They like enjoy the process and 

1006
00:59:56,880 --> 00:59:59,320
they enjoy doing it. 
That's one theory. 

1007
00:59:59,920 --> 01:00:03,640
The other theory is the 
infrastructure and the kind of 

1008
01:00:03,640 --> 01:00:06,880
standards around bridges haven't
matured enough. 

1009
01:00:07,080 --> 01:00:10,880
That builders feel comfortable 
integrating it or really pushing

1010
01:00:10,880 --> 01:00:15,200
it is another theory. 
Yeah, but. 

1011
01:00:15,240 --> 01:00:19,600
I think that that's the one that
kind of like I, I would probably

1012
01:00:19,600 --> 01:00:23,240
subscribe to kind of you don't 
want to bake something into your

1013
01:00:23,240 --> 01:00:26,840
system that you don't know is 
going to be around in six months

1014
01:00:26,840 --> 01:00:31,200
from now, right. 
So, so I think kind of as, as a 

1015
01:00:31,200 --> 01:00:34,000
builder kind of saying, OK, 
look, we'll just be agnostic 

1016
01:00:34,000 --> 01:00:36,880
here. 
That's often simpler. 

1017
01:00:38,040 --> 01:00:42,000
Yeah, I think you're probably 
right, or I think it's a working

1018
01:00:42,000 --> 01:00:45,080
theory, I should say that. 
And they also think wallets play

1019
01:00:45,080 --> 01:00:49,600
an important role here. 
SO77-O2 and putting smart 

1020
01:00:49,600 --> 01:00:52,880
contract wallets everywhere. 
I think it's huge for intense 

1021
01:00:52,880 --> 01:00:55,400
and huge for across. 
And this is something that 

1022
01:00:55,760 --> 01:00:57,880
frankly, we need to be a bit 
louder about. 

1023
01:00:58,640 --> 01:01:00,240
Other people need to be a bit 
louder about too. 

1024
01:01:00,840 --> 01:01:05,840
But if I have a smart contract 
wallet everywhere, there is a 

1025
01:01:05,840 --> 01:01:09,640
design pattern where I could 
keep my money on a home chain, 

1026
01:01:09,880 --> 01:01:12,120
like let's keep doing the A to B
example. 

1027
01:01:12,120 --> 01:01:14,880
So I keep my money on an 
arbitrum that's just my 

1028
01:01:14,880 --> 01:01:18,840
preferred bank, like home chain 
bank. 

1029
01:01:19,880 --> 01:01:24,480
But I can sign a user OP or sign
a message to do any arbitrary 

1030
01:01:24,480 --> 01:01:27,920
action on chain B, even if I 
have 0 money there, like 

1031
01:01:27,920 --> 01:01:32,920
absolutely 0 money there because
I can pay for that action from 

1032
01:01:32,920 --> 01:01:35,520
my home chain. 
And basically the, the kind of 

1033
01:01:35,520 --> 01:01:39,560
the abstraction here is I'm 
bridging the gas money to 

1034
01:01:39,600 --> 01:01:43,800
execute this user OP on chain B.
And I'm doing that incredibly 

1035
01:01:43,800 --> 01:01:47,680
quickly, right. 
And so, you know, once we have 

1036
01:01:47,680 --> 01:01:49,680
smart contract wallets 
everywhere on all the chains, 

1037
01:01:49,960 --> 01:01:56,240
this idea of, you know, I'm not 
really sending funds to the 

1038
01:01:56,240 --> 01:01:59,080
destination chain. 
I'm sending a message I want to 

1039
01:01:59,080 --> 01:02:02,760
execute and I'm like just in 
time delivering the money to pay

1040
01:02:02,760 --> 01:02:05,440
for that message. 
I mean, I think that's a very 

1041
01:02:05,440 --> 01:02:08,200
compelling feature of how you 
like unify all the chains and 

1042
01:02:08,200 --> 01:02:10,480
make everything feel like one 
network again. 

1043
01:02:12,200 --> 01:02:16,880
So that's, that's the UX that 
I'm most excited about. 

1044
01:02:18,680 --> 01:02:21,560
And I, I do think that's mainly 
going to be driven from the 

1045
01:02:21,560 --> 01:02:24,000
wallets. 
But then there's like 

1046
01:02:24,240 --> 01:02:27,040
fragmentation and sort of still 
a bunch. 

1047
01:02:27,040 --> 01:02:29,640
There's a bunch of people that 
are heard to to figure that one 

1048
01:02:29,640 --> 01:02:31,200
out too. 
Yeah. 

1049
01:02:31,320 --> 01:02:35,920
So I mean the the entire kind of
like smart, smart wallets on all

1050
01:02:35,920 --> 01:02:40,520
chains kind of thing there. 
There's a bunch of underlying 

1051
01:02:40,520 --> 01:02:44,360
problems that I think are not 
generally appreciated enough. 

1052
01:02:44,360 --> 01:02:49,200
So kind of for instance, I mean,
obviously kind of like now with 

1053
01:02:49,200 --> 01:02:52,960
create two kind of where you can
kind of create on the same 

1054
01:02:52,960 --> 01:02:54,800
address. 
But then what happens if you 

1055
01:02:54,800 --> 01:02:58,640
kind of lose one of the EO as on
one of the chains or kind of 

1056
01:02:58,640 --> 01:03:01,720
like you kind of you don't have 
all the EO as on all of the 

1057
01:03:01,720 --> 01:03:04,000
chains or kind of like there, 
there's a lot of kind of like 

1058
01:03:04,240 --> 01:03:06,480
what, what, what happens with 
recovery? 

1059
01:03:06,480 --> 01:03:10,440
And kind of like it's, it's a 
little bit of, of, of a messy 

1060
01:03:10,440 --> 01:03:13,880
situation. 
And I think, I mean, I've also 

1061
01:03:13,880 --> 01:03:17,360
always been in camp kind of we 
need smart wallets just because 

1062
01:03:17,360 --> 01:03:20,880
kind of like it's, it's clearly 
the way better user experience, 

1063
01:03:20,880 --> 01:03:25,200
But they are still there still 
are kind of a bunch of unsolved 

1064
01:03:25,560 --> 01:03:28,720
user problems kind of that come 
with it. 

1065
01:03:29,680 --> 01:03:31,240
Yeah. 
Well, like you have experience 

1066
01:03:31,240 --> 01:03:33,360
here, you know this right. 
This is like the being in 

1067
01:03:33,360 --> 01:03:37,800
industry and trying to not the 
theory but the practical like 

1068
01:03:37,800 --> 01:03:42,760
implementations here too. 
And I think like this is where 

1069
01:03:43,480 --> 01:03:46,600
what, what worries me is just it
takes longer because we've got 

1070
01:03:46,600 --> 01:03:48,760
to like figure these problems 
out, takes longer to get to the 

1071
01:03:48,760 --> 01:03:51,680
solution I want or I want to see
in the world. 

1072
01:03:53,920 --> 01:03:55,840
It doesn't change the fact that 
we're, I still think we're 

1073
01:03:55,840 --> 01:03:57,960
heading in the right path. 
Like you said, we need smart 

1074
01:03:57,960 --> 01:04:02,640
contract wallets everywhere. 
And then we need infrastructure.

1075
01:04:02,640 --> 01:04:05,080
And I really think of like what 
we're doing from intent 

1076
01:04:05,080 --> 01:04:07,080
bridging. 
It's, it's a layer of 

1077
01:04:07,080 --> 01:04:08,880
abstraction. 
Like the intent is just this 

1078
01:04:08,880 --> 01:04:12,920
layer of abstraction on top of 
some pretty complicated piping 

1079
01:04:13,040 --> 01:04:15,400
about how these genes might 
actually be connected. 

1080
01:04:15,720 --> 01:04:19,640
And so the solvers might be 
using finance to rebalance or 

1081
01:04:19,640 --> 01:04:20,920
whatever. 
It doesn't matter. 

1082
01:04:21,840 --> 01:04:25,240
There's just all this other 
piping under the surface that 

1083
01:04:25,240 --> 01:04:27,840
users shouldn't have to see 
because they're operating on 

1084
01:04:27,840 --> 01:04:29,920
this like thin intent layer of 
abstraction. 

1085
01:04:30,280 --> 01:04:33,680
And that I have a lot of 
conviction that that's like a 

1086
01:04:33,680 --> 01:04:36,880
necessary piece. 
I just want to get out there as 

1087
01:04:36,880 --> 01:04:40,960
fast as we can and then make the
user experience be as abstracted

1088
01:04:40,960 --> 01:04:43,800
as possible. 
But yeah, it might be a little 

1089
01:04:43,800 --> 01:04:47,600
bit for me to do that. 
How do you see the interplay 

1090
01:04:47,600 --> 01:04:52,400
between bridges, roll ups and 
shared sequencing? 

1091
01:04:52,400 --> 01:04:57,040
So kind of could could across 
one day kind of integrate with 

1092
01:04:57,200 --> 01:05:03,520
shared sequences. 
It's a really, a really good 

1093
01:05:03,520 --> 01:05:13,680
question and really nuanced. 
I, I, there are so many 

1094
01:05:13,920 --> 01:05:19,000
innovative technologies around 
like pieces of interoperability 

1095
01:05:19,960 --> 01:05:23,160
and, you know, to take A, to 
throw something else there that 

1096
01:05:23,160 --> 01:05:26,480
you didn't mention, like think 
ZK proof aggregation, kind of 

1097
01:05:26,480 --> 01:05:29,640
like some of what the like the 
egg layer stuff is doing to. 

1098
01:05:31,560 --> 01:05:35,440
There are ways that you're going
to, you're going to have really 

1099
01:05:35,440 --> 01:05:39,680
interesting ways to send 
messages between chains to and, 

1100
01:05:39,720 --> 01:05:43,320
and send funds shared sequencing
too. 

1101
01:05:43,320 --> 01:05:47,480
There's like, OK, so fun ways 
that a couple chains or some set

1102
01:05:47,480 --> 01:05:51,760
of chains could be, could do 
somewhat synchronous things 

1103
01:05:51,760 --> 01:05:56,240
between them. 
I think it's it's great when I 

1104
01:05:56,240 --> 01:06:00,520
look at this, there is no, 
there's no, no one technique 

1105
01:06:00,520 --> 01:06:01,720
that's going to touch 
everything. 

1106
01:06:02,640 --> 01:06:04,520
It's like there's going to be 
these like pockets of 

1107
01:06:04,520 --> 01:06:06,800
interoperability. 
And you see this with like, OK, 

1108
01:06:06,800 --> 01:06:10,120
so super chain might have some 
interoperability here and there 

1109
01:06:10,120 --> 01:06:14,320
might be, you know, some shared 
sequences over here and some egg

1110
01:06:14,320 --> 01:06:16,200
layer proof aggregation over 
here. 

1111
01:06:16,400 --> 01:06:18,960
And then these chains are 
connected by Binance over here. 

1112
01:06:19,160 --> 01:06:22,920
And you just have these like 
this Venn diagram that does not 

1113
01:06:22,920 --> 01:06:28,720
have everything under 1 circle. 
And the way I look at it is 

1114
01:06:29,120 --> 01:06:33,480
intense are that one circle kind
of layer of abstraction where we

1115
01:06:33,480 --> 01:06:36,680
basically put the solver in 
charge of figuring it out. 

1116
01:06:38,320 --> 01:06:41,400
And they can use any of these 
underlying techniques to do it 

1117
01:06:41,400 --> 01:06:45,520
faster and cheaper, which lets 
them deliver the intent product 

1118
01:06:45,960 --> 01:06:51,720
to users at a better price. 
So that's kind of how I see the 

1119
01:06:51,720 --> 01:06:53,360
interplay between all these 
things. 

1120
01:06:53,440 --> 01:06:56,640
Does that make any sense? 
Yeah, makes a lot of sense. 

1121
01:06:56,640 --> 01:06:59,000
I think there's still a lot of 
things to kind of like be hashed

1122
01:06:59,000 --> 01:07:01,480
out, but I think kind of this is
also kind of just the state of 

1123
01:07:01,480 --> 01:07:06,880
the of of the technology, right.
I kind of have one final thing 

1124
01:07:06,880 --> 01:07:09,600
kind of like I'd like to touch 
upon because we haven't actually

1125
01:07:09,600 --> 01:07:14,960
talked about it at all. 
So Uma and across kind of they 

1126
01:07:14,960 --> 01:07:19,480
are super cool projects and kind
of what I always find 

1127
01:07:20,000 --> 01:07:27,080
fascinating is how where kind of
your governance systems work. 

1128
01:07:27,160 --> 01:07:30,760
So kind of kind of if you look 
at the Daos kind of they are 

1129
01:07:30,760 --> 01:07:36,040
pretty they are pretty alive, 
right? 

1130
01:07:36,240 --> 01:07:41,200
So kind of if you look at at 
kind of your Daos and kind of 

1131
01:07:41,880 --> 01:07:46,000
the the common DAO, what do you 
think you guys are doing right? 

1132
01:07:47,720 --> 01:07:51,840
Wow. 
You know, it's funny because we 

1133
01:07:51,840 --> 01:07:55,840
just got some weird FUD on the 
Internet about attacking our 

1134
01:07:55,840 --> 01:07:59,760
governance. 
And it was wild because I 

1135
01:07:59,760 --> 01:08:01,280
generally agree. 
I think we've actually done a 

1136
01:08:01,280 --> 01:08:06,240
pretty good job on this. 
We've been around for a while. 

1137
01:08:07,400 --> 01:08:12,680
We actually have a lot of token 
holders that are not investors 

1138
01:08:12,840 --> 01:08:16,160
that hold like reasonable chunks
of tokens too, I think. 

1139
01:08:16,160 --> 01:08:19,439
And again, I don't actually 
track token addresses or know 

1140
01:08:19,439 --> 01:08:22,399
who people are. 
But by being around for a while,

1141
01:08:22,399 --> 01:08:27,720
we have former employees that 
like us, are happy with us and 

1142
01:08:27,720 --> 01:08:30,560
have chunks of tokens and 
actually participate in 

1143
01:08:30,560 --> 01:08:32,040
governance, which I think is 
cool. 

1144
01:08:34,120 --> 01:08:35,920
Yeah, for dictating. 
It's an interesting question. 

1145
01:08:35,920 --> 01:08:40,240
I mean, I appreciate it. 
But I think we try to have, we 

1146
01:08:40,240 --> 01:08:45,760
try to, I try to direct kind of 
our foundation that's doing the 

1147
01:08:45,760 --> 01:08:51,600
work risk labs to be relatively 
opinionated about what we think 

1148
01:08:51,600 --> 01:08:57,800
is good or bad in a way that 
minimizes Dow infighting. 

1149
01:08:58,000 --> 01:09:04,960
It's kind of what we try to do 
and we try to make proposals or 

1150
01:09:04,960 --> 01:09:09,880
suggestions that we think make a
lot of sense and have to be well

1151
01:09:09,880 --> 01:09:13,880
reasoned. 
And then we like, yeah, have a 

1152
01:09:13,880 --> 01:09:21,160
bit of an opinion. 
So I, I think in the spectrum of

1153
01:09:21,160 --> 01:09:26,040
like we are by no means 
operating like a centralized 

1154
01:09:26,120 --> 01:09:29,920
company, like centralized 
Delaware C Corp, but we're also 

1155
01:09:29,920 --> 01:09:33,040
not trying to be like, hey, 
community, you guys figure it 

1156
01:09:33,040 --> 01:09:35,960
all out too. 
We're trying to do something in 

1157
01:09:35,960 --> 01:09:38,120
the middle. 
We were basically like, here's 

1158
01:09:38,120 --> 01:09:40,399
what we think should happen from
the Risk Labs Foundation 

1159
01:09:40,399 --> 01:09:42,960
perspective. 
And we are looking for community

1160
01:09:42,960 --> 01:09:49,200
sign off on it, which frankly is
like it, it is like how a 

1161
01:09:50,000 --> 01:09:52,960
Delaware C Corp shareholders 
interact. 

1162
01:09:53,000 --> 01:09:57,040
It's like a management team 
makes a shareholder proposal and

1163
01:09:57,040 --> 01:09:58,760
we ask shareholders to vote on 
it, right. 

1164
01:09:59,600 --> 01:10:03,240
So I think that's the the kind 
of analogy we've been going for.

1165
01:10:06,080 --> 01:10:10,680
For people who kind of want to 
become involved with either UMA 

1166
01:10:10,680 --> 01:10:14,400
or Cross or kind of who want to 
build on top of you guys, where 

1167
01:10:14,400 --> 01:10:17,920
do we send them? 
So you can follow me on Twitter 

1168
01:10:17,920 --> 01:10:23,040
at Hal 2001. 
It's my initials Hal 2001, which

1169
01:10:23,040 --> 01:10:25,040
is also from 2001 a space 
Odyssey. 

1170
01:10:25,040 --> 01:10:27,960
But you can follow me at Hal 
2001 on on X or Twitter. 

1171
01:10:28,720 --> 01:10:32,080
And then the two projects, it's 
a cross protocol and UMA 

1172
01:10:32,080 --> 01:10:36,960
protocol on on X or Twitter. 
Follow us there. 

1173
01:10:38,160 --> 01:10:42,680
We we're hiring and building 
actually a lot of fun stuff. 

1174
01:10:42,680 --> 01:10:46,920
Sorry, small plug. 
And you know, we're trying to 

1175
01:10:46,920 --> 01:10:49,840
engage in like there's a bunch, 
there's a bunch of really 

1176
01:10:49,840 --> 01:10:53,160
interesting stuff going on both 
on like the polymarket side, how

1177
01:10:53,160 --> 01:10:55,360
do we actually scale this 
Oracle? 

1178
01:10:55,360 --> 01:10:59,400
How do we use AI in this? 
And then on the bridging side, 

1179
01:10:59,600 --> 01:11:04,120
how do we like make Ethereum and
make Web 3 just feel like one 

1180
01:11:04,120 --> 01:11:07,200
network again? 
So I'm pretty pumped about our 

1181
01:11:07,520 --> 01:11:12,560
near term objectives too. 
Super cool, thank you for being 

1182
01:11:12,640 --> 01:11:14,600
on. 
Thank you so much for having me 

1183
01:11:14,600 --> 01:11:15,040
really fun.