1
00:00:00,300 --> 00:00:05,100
This is epicenter episode 447 
where the guest Arjun book Tani.

2
00:00:19,200 --> 00:00:22,200
Welcome to epicenter the show 
which talks about Technologies 

3
00:00:22,200 --> 00:00:25,000
projects and people driving 
decentralization and blockchain 

4
00:00:25,000 --> 00:00:27,100
Revolution. 
I'm afraid to take a chance. 

5
00:00:27,100 --> 00:00:29,500
And today, I'm speaking with our
general plan e who is the 

6
00:00:29,500 --> 00:00:33,600
founder of connects connects is 
a bridge project and we will 

7
00:00:33,600 --> 00:00:36,200
talk about this in detail in 
just a bit. 

8
00:00:36,300 --> 00:00:39,000
But let me tell you about our 
sponsors today. 

9
00:00:40,400 --> 00:00:44,000
Our first one says Tallyho Hello
is redefining the wallet as a 

10
00:00:44,000 --> 00:00:46,600
public good. 
You can think of it as a 

11
00:00:46,600 --> 00:00:50,000
community-owned, alternative to 
metal, mask with Teddy, how you 

12
00:00:50,000 --> 00:00:52,500
can enter the matter verse, 
where the web three wallet. 

13
00:00:52,500 --> 00:00:54,600
That's fully Community owned and
operated. 

14
00:00:54,800 --> 00:00:57,300
And it's the first wallet that 
is also it. 

15
00:00:57,300 --> 00:01:00,500
How tell you how his commitment 
to community ownership in public

16
00:01:00,500 --> 00:01:03,600
goods, stretches beyond the 
wallet, in January. 

17
00:01:03,600 --> 00:01:06,900
They became the first one. 
So of ether, JS and open source,

18
00:01:06,900 --> 00:01:09,900
JavaScript library, helping 
developers connect to a theorem.

19
00:01:10,300 --> 00:01:13,300
And they recently announced a 
pledge to commit two point, five

20
00:01:13,300 --> 00:01:16,500
percent of their total token 
Supply to get coin Aqueduct, 

21
00:01:17,200 --> 00:01:20,400
head over to Terry holder, cash 
to try Telly, whole Community 

22
00:01:20,400 --> 00:01:23,800
Edition and play around with its
features before its upcoming 

23
00:01:24,100 --> 00:01:28,500
version 1 and our launch. 
Our next one says chorus, one 

24
00:01:29,200 --> 00:01:32,600
securing blockchains and earning
rewards need not be 

25
00:01:32,600 --> 00:01:35,700
energy-intensive are complicated
and by staking your assets. 

26
00:01:35,700 --> 00:01:38,300
With course one you contribute 
to network security and earn 

27
00:01:38,300 --> 00:01:41,500
rewards to course, one has been 
a Pioneer in this space. 

28
00:01:41,800 --> 00:01:46,000
Since 2018 and secures billions 
of dollars in assets on over 25 

29
00:01:46,000 --> 00:01:49,000
decentralized networks, 
including Solana Cosmos and the 

30
00:01:49,000 --> 00:01:51,800
theorem your institution. 
Are you want to run your own 

31
00:01:51,800 --> 00:01:55,300
branded node, you can use cars 
once white label Services. 

32
00:01:55,300 --> 00:01:57,600
There are M and their 
battle-proven infrastructure to 

33
00:01:57,600 --> 00:01:59,600
participate in proof of State 
networks. 

34
00:01:59,600 --> 00:02:03,200
In an easy way chorus 1. 
Kim also released an exclusive 

35
00:02:03,200 --> 00:02:06,600
report on the important events 
and Trends from the first 

36
00:02:06,600 --> 00:02:10,000
quarter of 2022 and you can read
it now for free on their 

37
00:02:10,000 --> 00:02:13,300
website. 
I'm at Or start one and where 

38
00:02:13,300 --> 00:02:15,400
you can also start your staking 
Journey. 

39
00:02:16,200 --> 00:02:19,600
Our final sponsors para swap. 
Car swap is a multi-chain decks 

40
00:02:19,600 --> 00:02:22,000
aggregator. 
This means that group are swap. 

41
00:02:22,000 --> 00:02:25,000
You can easily access the 
liquidity of various different 

42
00:02:25,000 --> 00:02:28,100
decentralised exchanges. 
The project called automatically

43
00:02:28,100 --> 00:02:30,100
finds the cheapest liquidity for
you. 

44
00:02:30,400 --> 00:02:33,000
So you can trade knowing that 
you're getting the best price. 

45
00:02:33,500 --> 00:02:37,400
How Schwab is also gas friendly 
and that helps keeping your 

46
00:02:37,400 --> 00:02:41,100
transaction costs low Airsoft 
recently added support for 

47
00:02:41,100 --> 00:02:43,700
Avalanche. 
One and BAC and Phantom, you can

48
00:02:43,700 --> 00:02:47,400
also use Periscope directly from
your Legend Edge alive, and they

49
00:02:47,400 --> 00:02:50,200
are becoming a dull. 
So if you have PSP tokens, maybe

50
00:02:50,200 --> 00:02:52,900
from the a drop, that is 
something you can participate 

51
00:02:52,900 --> 00:02:56,100
in. 
There's also a vote on the gas 

52
00:02:56,100 --> 00:03:00,900
refunds program that just passed
in the Paris opt out and this 

53
00:03:00,900 --> 00:03:05,800
will allow periscopes takers to 
get up to a 100%, gas, refund on

54
00:03:05,800 --> 00:03:09,700
their trades, on top of their 
order compounding geared so 

55
00:03:09,700 --> 00:03:12,500
business, visit Paris WAP to 
learn more More Periscope. 

56
00:03:12,500 --> 00:03:18,200
Dot IO / epicenter. 
Aizen, it's so good to have you 

57
00:03:18,200 --> 00:03:21,100
on. 
Thank you so much for having me.

58
00:03:22,100 --> 00:03:24,800
Imagine and tell us about 
yourself. 

59
00:03:25,000 --> 00:03:26,800
How did you get your start in 
this industry? 

60
00:03:28,500 --> 00:03:33,100
Yeah, so I started being 
interested in. 

61
00:03:33,500 --> 00:03:35,700
I started building on top of the
theorem in 2016. 

62
00:03:35,700 --> 00:03:37,500
I was always kind of like 
tangentially interested in 

63
00:03:37,500 --> 00:03:42,100
crypto, because I was involved 
with a lot of the like P2P 

64
00:03:42,600 --> 00:03:46,300
community in like the IRC days, 
but I ended up missing the boat 

65
00:03:46,300 --> 00:03:49,100
on bitcoin for some reason. 
I was just, I was personally, 

66
00:03:49,100 --> 00:03:52,300
just not very interested in it 
for some reason and then it 

67
00:03:52,300 --> 00:03:54,100
wasn't until it cerium came 
along. 

68
00:03:54,100 --> 00:03:57,200
And I kind of discovered it in 
2016 that it clicked for me that

69
00:03:57,200 --> 00:04:00,400
you could use. 
This technology to build public 

70
00:04:00,400 --> 00:04:03,500
goods, like truly public 
non-sovereign non-corporate 

71
00:04:03,500 --> 00:04:06,100
goods that are similar to the 
internet that can be like 

72
00:04:06,100 --> 00:04:09,500
globally accessible. 
And can we can be this like big 

73
00:04:09,500 --> 00:04:14,000
equalizing force in the in the 
world economy after that. 

74
00:04:14,000 --> 00:04:19,200
So I started playing around with
the technology in 2016 built 

75
00:04:19,200 --> 00:04:21,399
some infrastructure and worked 
with a couple of projects that 

76
00:04:21,399 --> 00:04:25,900
the time I started the ethereum 
SF ethereum developers meet up, 

77
00:04:25,900 --> 00:04:28,600
which is pretty awesome because 
I was one of the First like 

78
00:04:28,600 --> 00:04:31,900
communities that was like 
actively building on top of on 

79
00:04:31,900 --> 00:04:34,900
top of ethereum. 
And then in 2017. 

80
00:04:35,300 --> 00:04:38,900
I ended up starting connects to 
because I sort of had a lot of 

81
00:04:38,907 --> 00:04:41,400
conviction on the technology 
like aetherium as a broader 

82
00:04:41,400 --> 00:04:43,800
technology and on this 
decentralization movement. 

83
00:04:44,600 --> 00:04:50,200
And my goal was just how can we 
bring this technology to a 

84
00:04:50,207 --> 00:04:51,700
billion people as fast as 
possible? 

85
00:04:53,200 --> 00:04:56,100
Quit. 
So, before we actually dive into

86
00:04:56,100 --> 00:04:59,400
context and he was also one of 
the summoner's of the Monarch 

87
00:04:59,400 --> 00:05:01,600
Tower, right? 
Yes. 

88
00:05:02,000 --> 00:05:03,900
Yeah. 
So I helped to design them elect

89
00:05:03,900 --> 00:05:06,800
out alongside Al. 
I mean soleimani, and then 

90
00:05:06,800 --> 00:05:10,800
helped build it with my current 
co-founders, laying Heyburn, 

91
00:05:10,800 --> 00:05:14,400
Rahul set, the ROM, and then one
of the cofounders of Spain at 

92
00:05:14,400 --> 00:05:17,200
the time, James Young along 
with, I mean. 

93
00:05:17,700 --> 00:05:21,800
And, and then the, I guess the 
idea at the time was we were 

94
00:05:21,800 --> 00:05:23,500
really interested. 
In solving, this like 

95
00:05:23,600 --> 00:05:27,100
coordination problem that that 
we kind of felt that we had 

96
00:05:27,100 --> 00:05:30,900
around, you know, working 
collaborating this function on, 

97
00:05:30,900 --> 00:05:32,800
on building scalability 
infrastructure. 

98
00:05:33,500 --> 00:05:35,800
And also was just like a broader
coordination problem that we saw

99
00:05:35,800 --> 00:05:39,100
in the space and, and in the 
world more generally, and the 

100
00:05:39,100 --> 00:05:42,200
idea was that like, we wanted to
create some sort of, like, 

101
00:05:42,200 --> 00:05:48,200
public resource for organizing, 
like, like, Community Action 

102
00:05:48,200 --> 00:05:51,500
around public goods without 
necessarily having like, 

103
00:05:51,500 --> 00:05:55,600
basically having that Yet public
resource itself and the that 

104
00:05:55,600 --> 00:05:57,000
idea kind of became the moloch 
doubt. 

105
00:05:57,000 --> 00:06:00,500
The first really, really the 
first like down framework, that 

106
00:06:00,500 --> 00:06:03,800
actually ended up getting 
traction, which is pretty 

107
00:06:03,800 --> 00:06:05,500
awesome. 
We didn't, we didn't really like

108
00:06:05,500 --> 00:06:07,400
ever expect that to be the case.
We were just kind of playing 

109
00:06:07,400 --> 00:06:10,800
around with the ideas and the 
goal behind. 

110
00:06:10,800 --> 00:06:13,300
It was never like here is the 
solution to coordination. 

111
00:06:13,300 --> 00:06:16,600
It was like, here is a process 
by which a cure is an initial 

112
00:06:16,600 --> 00:06:19,400
step, and then a process and a 
mean by which we can eventually 

113
00:06:19,400 --> 00:06:22,000
hope to solve coordination more 
generally. 

114
00:06:22,600 --> 00:06:26,400
But the idea was always like, it
won't necessarily happen. 

115
00:06:26,400 --> 00:06:28,600
It might not even necessarily 
happen as a marked out, but 

116
00:06:28,600 --> 00:06:31,600
hopefully, this can be the 
Catalyst to start people 

117
00:06:31,600 --> 00:06:33,600
thinking about this problem or 
more generally. 

118
00:06:36,000 --> 00:06:38,700
Yeah, I mean what it was 
definitely a right time. 

119
00:06:38,700 --> 00:06:40,700
Right place moment. 
And I mean basically the 

120
00:06:40,700 --> 00:06:45,100
narrative behind it was just 
compelling in in in the light of

121
00:06:45,900 --> 00:06:49,300
the perceived weakness of the 
theorem foundation and basically

122
00:06:49,300 --> 00:06:53,100
building things for the 
community. 

123
00:06:53,100 --> 00:06:57,900
So yeah, I think this was it was
a great launch. 

124
00:06:58,100 --> 00:07:01,200
So tell us about connects the 
way she connects actually 

125
00:07:01,200 --> 00:07:08,700
started off as a state channels 
protocol. yes, so yeah, when we 

126
00:07:08,700 --> 00:07:11,600
when we started connects, like I
mentioned earlier, like the the 

127
00:07:11,600 --> 00:07:15,500
key goal was always this 
technology ethereum specifically

128
00:07:15,500 --> 00:07:20,100
and I guess like, decentralized 
systems has the capacity to 

129
00:07:20,100 --> 00:07:23,900
really improve to meaningfully 
rewrite, the way that human 

130
00:07:23,900 --> 00:07:27,200
beings coordinate at a global 
scale to move away from public 

131
00:07:27,200 --> 00:07:29,700
infrastructure that is owned by 
governments or, you know, 

132
00:07:29,700 --> 00:07:31,700
large-scale infrastructure is 
owned by like operated by 

133
00:07:31,707 --> 00:07:37,700
corporations and and towards 
making That infrastructure part 

134
00:07:37,700 --> 00:07:40,300
of the comments globally 
accessible in the same way that 

135
00:07:40,300 --> 00:07:41,600
the internet is globally 
accessible. 

136
00:07:42,600 --> 00:07:45,300
And, and it comes from this, 
like shared belief that the team

137
00:07:45,300 --> 00:07:48,500
had released the founders had 
that like things like, you know,

138
00:07:48,500 --> 00:07:53,700
Google search things, like money
things like coordination 

139
00:07:53,700 --> 00:07:58,000
tooling, like voting things like
that are should be accessible to

140
00:07:58,000 --> 00:08:01,200
everyone in a fair and 
egalitarian way regardless of 

141
00:08:01,200 --> 00:08:04,400
where they live, which is not 
currently true for the majority 

142
00:08:04,400 --> 00:08:06,600
of the world. 
And so the goal was always like 

143
00:08:06,600 --> 00:08:10,000
let's take this this technology 
and let's find a way to scale it

144
00:08:10,000 --> 00:08:12,100
to the world. 
And of course that pretty 

145
00:08:12,100 --> 00:08:14,300
quickly led us to scalability 
research because I was like one 

146
00:08:14,300 --> 00:08:17,800
of the biggest kind of blockers 
to being able to have many, many

147
00:08:17,900 --> 00:08:21,400
potentially a billion peepers. 
People use this use of use 

148
00:08:21,400 --> 00:08:25,400
ethereum in 2018, when we 
started looking at this and it 

149
00:08:25,400 --> 00:08:28,600
started doing like scalability 
research, the there wasn't 

150
00:08:28,600 --> 00:08:32,400
really a lot out there. 
The this most of the research 

151
00:08:32,400 --> 00:08:34,799
had been at that point B focused
on state channels. 

152
00:08:35,200 --> 00:08:38,000
And like Raven was kind of like 
the the leading project on that 

153
00:08:38,000 --> 00:08:41,799
at the time. 
And then there was new research 

154
00:08:41,799 --> 00:08:43,299
that was being done about 
plasma. 

155
00:08:44,300 --> 00:08:48,000
We, of course, ended up jumping 
into State channels because to 

156
00:08:48,000 --> 00:08:50,100
us, it seemed like the lowest 
hanging fruit. 

157
00:08:50,100 --> 00:08:51,700
Use case, was actually going to 
be payments. 

158
00:08:52,400 --> 00:08:54,500
And this is just a hypothesis 
that we came up with based on, 

159
00:08:54,500 --> 00:08:56,900
like, what we saw in the space 
of the time, which was projects 

160
00:08:56,900 --> 00:08:59,700
like spank chain, and others who
were doing, you know, some form 

161
00:08:59,700 --> 00:09:02,900
of payments. 
And then, and then, of course, 

162
00:09:02,900 --> 00:09:05,700
like, you know, Plasma Research 
continued over the The next few 

163
00:09:05,700 --> 00:09:08,000
years, we kind of like expanded 
our understanding of say, 

164
00:09:08,000 --> 00:09:11,200
Charles and things like that. 
And we also moved towards like 

165
00:09:11,200 --> 00:09:14,300
building, you know, Roll-Ups as 
like a more generalized 

166
00:09:14,300 --> 00:09:16,700
scalability solution, which has 
less scalability, but is like 

167
00:09:17,100 --> 00:09:19,800
can be used for any kind of like
arbitrary smart Contracting. 

168
00:09:20,500 --> 00:09:22,800
One thing that we found and this
is the reason that we ended up 

169
00:09:22,800 --> 00:09:26,400
moving away from State channels,
is just like a lot of our, you 

170
00:09:26,400 --> 00:09:29,700
know, we were a largely Rd org 
for a very long time. 

171
00:09:29,700 --> 00:09:32,800
We like had a very very small 
team. 

172
00:09:32,800 --> 00:09:35,000
That was very very leave and 
very hungry. 

173
00:09:35,200 --> 00:09:39,900
And like extremely careful about
like the things that we built in

174
00:09:39,900 --> 00:09:42,300
about making sure that we only 
Built the most minimal possible 

175
00:09:42,300 --> 00:09:44,400
solutions. 
One of the things that we 

176
00:09:44,400 --> 00:09:47,400
consistently found though. 
Was that while there was a lot 

177
00:09:47,400 --> 00:09:50,800
of interest in payments and 
around scaling payments as a 

178
00:09:50,800 --> 00:09:53,000
market. 
There are actually very few use 

179
00:09:53,000 --> 00:09:56,700
cases that scaled associated 
with payments more generally and

180
00:09:56,700 --> 00:09:59,800
in and you can actually, if you 
look out a the space right now, 

181
00:09:59,800 --> 00:10:02,600
you can actually it's pretty 
easy to tell that like payments 

182
00:10:02,600 --> 00:10:04,200
actually hasn't taken off crypto
payments. 

183
00:10:04,200 --> 00:10:06,300
Surprisingly the At the fact 
that many people have had a 

184
00:10:06,308 --> 00:10:07,900
thesis about it for, like, 
almost. 

185
00:10:07,900 --> 00:10:10,700
Okay. 
Now, for some reason payments 

186
00:10:10,700 --> 00:10:13,200
haven't actually achieved a lot 
of Market penetration in the 

187
00:10:13,200 --> 00:10:16,000
broader audience compared to 
things like defy and governance.

188
00:10:16,500 --> 00:10:19,800
And so, we ended up realizing 
that like, the solution that we 

189
00:10:19,800 --> 00:10:21,200
were building. 
The technology that we were 

190
00:10:21,200 --> 00:10:24,900
building in researching, was not
necessarily a technology, that 

191
00:10:24,900 --> 00:10:27,500
was mapping very well to the 
real needs of users. 

192
00:10:27,600 --> 00:10:30,600
And, and at the same time, what 
we realized this is actually 

193
00:10:30,600 --> 00:10:35,600
very fortuitous, but in 2020, we
there was a Know if you remember

194
00:10:35,600 --> 00:10:38,400
this, but there was that there 
was a Bake-Off that read it 

195
00:10:38,400 --> 00:10:40,700
created is it was like a 
scalability Bake-Off between 

196
00:10:40,700 --> 00:10:42,400
like the different LT Solutions?
Yeah. 

197
00:10:42,400 --> 00:10:46,700
I told you I'm but that. 
Oh, yeah, so we actually, this 

198
00:10:46,700 --> 00:10:48,900
was actually the time when we 
were having this kind of, like, 

199
00:10:48,900 --> 00:10:51,300
question these questions around 
payments, it around like payment

200
00:10:51,300 --> 00:10:53,700
related, use cases. 
And one thing that we saw was 

201
00:10:53,700 --> 00:10:55,700
like, in this Bake-Off. 
This was sort of like a 

202
00:10:55,700 --> 00:10:58,700
quintessential example of like a
decentralised ecosystem that 

203
00:10:58,700 --> 00:11:00,100
wanted to build on top of 
scalability. 

204
00:11:00,100 --> 00:11:03,200
So sure and what we found was 
like all like looking out at all

205
00:11:03,200 --> 00:11:05,400
of the other submissions that 
have been put in place all All 

206
00:11:05,400 --> 00:11:08,600
of them operated like chains and
we did, we had like, we 

207
00:11:08,600 --> 00:11:11,100
basically have two would have to
would have had to go and build a

208
00:11:11,100 --> 00:11:13,600
very custom piece of 
infrastructure for Reddit, 

209
00:11:13,600 --> 00:11:17,400
specifically designed for their 
use case and even then they 

210
00:11:17,400 --> 00:11:19,200
would have been like gotchas and
things like that, that we have 

211
00:11:19,200 --> 00:11:22,400
to worry about where as you 
know, which is nowhere near as 

212
00:11:22,400 --> 00:11:25,900
like nice is just deploying the 
exact same contracts that you 

213
00:11:25,900 --> 00:11:27,800
have on top of ism orbitrim. 
Right? 

214
00:11:28,900 --> 00:11:32,200
And and I think what that helped
us realize was that maybe maybe 

215
00:11:32,200 --> 00:11:33,500
we were just on the wrong track,
right? 

216
00:11:33,500 --> 00:11:37,200
Like if we're trying to compete,
Eat with Roll-Ups as a state 

217
00:11:37,200 --> 00:11:39,600
shown at work, to try to scale 
something. 

218
00:11:39,600 --> 00:11:42,100
That is not payments. 
We're not going to succeed, 

219
00:11:42,300 --> 00:11:44,000
because we would have had to do 
a ton of custom work. 

220
00:11:44,200 --> 00:11:47,300
But at the same time, the 
secondary problem that we saw 

221
00:11:48,100 --> 00:11:49,900
and this is actually just 
really, really lucky. 

222
00:11:49,900 --> 00:11:52,300
We just sort of said, okay. 
Well, you know, there's all of 

223
00:11:52,300 --> 00:11:56,700
these projects have this like 
big drawback, which is, you 

224
00:11:56,700 --> 00:11:58,700
know, once you're locked once 
you're on one of these 

225
00:11:58,700 --> 00:12:00,900
Solutions, it's really difficult
to get in and out of it. 

226
00:12:01,300 --> 00:12:03,400
It's really hard to get between 
these different solutions. 

227
00:12:03,400 --> 00:12:08,100
Why don't we just It our exact 
say talent for structure and use

228
00:12:08,100 --> 00:12:10,500
it to allow people to send 
Community points, right at 

229
00:12:10,500 --> 00:12:12,300
Community points, between these 
different options. 

230
00:12:13,300 --> 00:12:16,200
And that's what we did. 
We actually submitted an 

231
00:12:16,200 --> 00:12:19,100
alternative solution to the 
scalability back off. 

232
00:12:19,100 --> 00:12:21,000
We obviously didn't win because 
we didn't even use, we didn't 

233
00:12:21,000 --> 00:12:24,600
even technically participate, 
but we actually did get a lot of

234
00:12:24,600 --> 00:12:25,800
attention, both from the 
community. 

235
00:12:25,800 --> 00:12:28,100
And also for Reddit, where 
people looked at. 

236
00:12:28,300 --> 00:12:30,200
And, and also from all this 
giblet e-solutions because 

237
00:12:30,200 --> 00:12:34,000
people realize, oh wait, you can
use State channels to use other 

238
00:12:34,000 --> 00:12:38,400
kinds of technology to To allow 
for seamless, bridging seamless.

239
00:12:38,400 --> 00:12:41,900
Communication between at the 
time, it was like optimism 

240
00:12:41,900 --> 00:12:45,800
arbitrary mxd, polygon scale and
a bunch of other tests Nets. 

241
00:12:47,700 --> 00:12:50,900
So yeah, it was kind of cool 
that actually we sort of did it 

242
00:12:50,900 --> 00:12:55,200
as a like let's not play a game 
that we know that we won't win 

243
00:12:55,200 --> 00:12:57,300
thing. 
And you know, we kind of felt 

244
00:12:57,300 --> 00:12:59,600
like we had to submit something 
but we didn't really know what 

245
00:12:59,800 --> 00:13:03,800
so we did this instead and it 
turned into US stumbling upon 

246
00:13:03,800 --> 00:13:06,800
this really really big. really, 
really interesting Market that 

247
00:13:07,300 --> 00:13:12,800
at the time, no one else had 
really even thought about Yeah, 

248
00:13:12,800 --> 00:13:16,100
I mean, let's talk about the 
history of interoperability in 

249
00:13:16,100 --> 00:13:20,000
the history of bridges in just a
little bit, just as an aside. 

250
00:13:20,600 --> 00:13:24,200
Why do you think payments has 
never really taken off because 

251
00:13:24,200 --> 00:13:26,900
it seems like it's such a low 
hanging fruit, right? 

252
00:13:28,000 --> 00:13:31,300
Yeah. 
Yeah, that's a really really 

253
00:13:31,300 --> 00:13:34,600
good question. 
I think that's there's a lot of 

254
00:13:34,600 --> 00:13:38,300
reasons. 
The first is the first and main 

255
00:13:38,300 --> 00:13:41,100
reason is that the payments 
Market itself is just incredibly

256
00:13:41,100 --> 00:13:42,700
complex. 
And there's like these really, 

257
00:13:42,700 --> 00:13:47,900
really deep and trench Network 
effects associated with the 

258
00:13:47,900 --> 00:13:53,400
existing structure of like like 
like payment facilitating Banks,

259
00:13:53,700 --> 00:13:56,300
payment processors, Visa 
Mastercard, and other like 

260
00:13:56,300 --> 00:14:00,200
payment systems, that makes it 
really, really difficult to Into

261
00:14:00,200 --> 00:14:03,300
this market and and like a 
functional way outside of 

262
00:14:03,700 --> 00:14:06,600
outside of like places where 
that are just like completely on

263
00:14:06,600 --> 00:14:08,900
backed. 
And I think, I think that made 

264
00:14:08,900 --> 00:14:11,600
it quite difficult at the time 
because like, you just had a 

265
00:14:11,600 --> 00:14:14,800
really hard time finding markets
of users that actually cared 

266
00:14:14,800 --> 00:14:18,900
about crypto payments, you know,
we ran a bunch of experiments in

267
00:14:18,900 --> 00:14:20,600
like gaming. 
We ran a bunch of experiments of

268
00:14:20,600 --> 00:14:22,000
content. 
We write a bunch of experiments 

269
00:14:22,000 --> 00:14:24,900
in like countries, where there 
were large percentage of people 

270
00:14:24,900 --> 00:14:27,400
unbanked, and, like, we kept 
running into these, like, 

271
00:14:27,400 --> 00:14:30,000
problems associated with, like, 
people being like, Okay. 

272
00:14:30,000 --> 00:14:32,000
Well, you know, you're having to
go through all of this 

273
00:14:32,000 --> 00:14:34,000
additional friction to get 
crypto in the first place. 

274
00:14:34,000 --> 00:14:35,700
What is the benefit of doing 
this versus? 

275
00:14:35,700 --> 00:14:37,900
Like finding some other 
mechanism to pay? 

276
00:14:38,100 --> 00:14:40,800
And like why not just use mobile
payments or why not just use 

277
00:14:40,800 --> 00:14:43,300
like in-game payments, things 
like that. 

278
00:14:44,000 --> 00:14:47,000
So I think I think the the real 
reason is really just that like 

279
00:14:47,400 --> 00:14:50,400
it's the same reason why we 
can't just like fully replace 

280
00:14:50,400 --> 00:14:52,100
all voting with crypto voting, 
right? 

281
00:14:52,100 --> 00:14:54,100
It's, there's some of these 
there's there's some of these, 

282
00:14:54,100 --> 00:14:56,300
like, really obvious use cases, 
that people always talk about 

283
00:14:56,300 --> 00:14:58,700
like, oh, well, someone should 
just build a voting system on 

284
00:14:58,700 --> 00:15:01,400
top of blockchains and then We 
can just use that everywhere as 

285
00:15:01,400 --> 00:15:03,000
an alternative to existing 
building and it gives 

286
00:15:03,000 --> 00:15:05,900
transparency and things like 
that and it would but it would 

287
00:15:05,900 --> 00:15:09,800
only work if like it's like not 
intrinsically a 10x Improvement 

288
00:15:09,800 --> 00:15:13,300
against what exists right now. 
And and because there are these 

289
00:15:13,300 --> 00:15:15,700
entrenched Network effects with 
what exists right now. 

290
00:15:16,100 --> 00:15:18,500
I don't think that we'll be able
to get to the point where it's 

291
00:15:18,500 --> 00:15:22,100
like worthwhile to make that 
kind of upgrade for any user 

292
00:15:22,300 --> 00:15:25,200
unless they already are 
on-boarded into crypto. 

293
00:15:25,700 --> 00:15:29,800
So, you know, I think for that 
reason, things like defy, our A 

294
00:15:29,800 --> 00:15:32,200
much better like initial 
onboarding mechanism because 

295
00:15:32,700 --> 00:15:34,900
it's a 10x Improvement against 
what exists currently. 

296
00:15:34,900 --> 00:15:37,600
Because, as a user, your you 
have access to like, being able 

297
00:15:37,600 --> 00:15:40,200
to earn a lot more money online.
Then you would have ever been 

298
00:15:40,200 --> 00:15:43,600
able to, in the past, right? 
Like defy has on-boarded large 

299
00:15:43,600 --> 00:15:48,100
parts of Southeast Asia, you 
know, after like sub-Saharan 

300
00:15:48,100 --> 00:15:52,100
Africa Latin America because in 
a lot of those places like 

301
00:15:52,100 --> 00:15:54,800
contributing to different 
ecosystems or participating in 

302
00:15:54,800 --> 00:15:58,400
airdrops, things like that, 
actually means life-changing 

303
00:15:58,400 --> 00:16:01,600
money, like that's that's And 
access that you would never have

304
00:16:01,600 --> 00:16:05,700
had before whereas participating
in like, getting on board into a

305
00:16:05,700 --> 00:16:09,900
payment system or two voting 
system isn't necessarily going 

306
00:16:09,900 --> 00:16:15,200
to be as big of a change to you.
Would you venture guess when we 

307
00:16:15,200 --> 00:16:18,300
will see the first large-scale 
crypto based payment system. 

308
00:16:20,800 --> 00:16:23,400
I mean, technically the it 
already exists technically, 

309
00:16:23,400 --> 00:16:26,400
there are some mechanics some 
instances of like large-scale 

310
00:16:26,400 --> 00:16:29,600
crypto based Payment Systems. 
The graph is a good example, 

311
00:16:29,900 --> 00:16:31,800
like we worked really closely 
with them when you were doing 

312
00:16:31,800 --> 00:16:34,000
stay Channel stuff because 
they're like, I think there are 

313
00:16:34,000 --> 00:16:37,800
the single largest operator of 
like a micro payment Network in 

314
00:16:37,808 --> 00:16:41,700
the world right now. 
I believe I mean, depends how 

315
00:16:41,700 --> 00:16:43,600
you classify micropayments. 
But at least at the scale that 

316
00:16:43,600 --> 00:16:47,100
they're doing it and and then 
similar to, you know, similarly 

317
00:16:47,100 --> 00:16:50,500
like Sia file coin and many 
others are also like working. 

318
00:16:50,700 --> 00:16:52,000
On building out their own 
Mystic. 

319
00:16:52,000 --> 00:16:53,900
Bespoke likes a child, the 
plantations if they haven't 

320
00:16:53,900 --> 00:16:55,300
already. 
I think I already has one. 

321
00:16:55,700 --> 00:16:57,400
And and so I think I think it 
exists. 

322
00:16:57,400 --> 00:17:01,200
It's just like it's just like 
been a much slower bird. 

323
00:17:02,100 --> 00:17:04,800
I would expect that. 
This would happen for 

324
00:17:04,800 --> 00:17:07,400
micropayments. 
It'll basically happen when the 

325
00:17:07,400 --> 00:17:11,099
like web 3 infrastructure. 
Boom of like different kinds of 

326
00:17:11,099 --> 00:17:14,400
web three, protocols, Computing 
networks and resource networks 

327
00:17:14,400 --> 00:17:16,800
scales. 
It hasn't scaled yet, but it's 

328
00:17:16,800 --> 00:17:19,700
starting to get there. 
And then I would think for like 

329
00:17:19,700 --> 00:17:21,500
consumer payments. 
It's not going to happen until 

330
00:17:21,500 --> 00:17:23,200
like everybody has a crypto 
wallet. 

331
00:17:24,900 --> 00:17:28,300
Yeah, I think that's a faggus. 
So let's talk about the history 

332
00:17:28,300 --> 00:17:32,000
of interoperability because 
basically that's been one of 

333
00:17:32,000 --> 00:17:37,800
those Arenas of web three that 
have actually gathered a lot 

334
00:17:37,800 --> 00:17:40,000
more traction than initially 
thought. 

335
00:17:40,000 --> 00:17:41,600
Right. 
So basically back in the day, 

336
00:17:41,800 --> 00:17:47,700
kind of the idea of different 
blockchains kind of talking to 

337
00:17:47,700 --> 00:17:50,400
each other and having like trust
as Bridges and stuff. 

338
00:17:50,400 --> 00:17:56,600
This seemed like magic and I 
remember, even even hearing 

339
00:17:56,600 --> 00:18:02,500
about, you know, Jays I IBC 
Vision back in the day. 

340
00:18:02,700 --> 00:18:06,600
They seemed like I asked myself.
This is actually feasible and we

341
00:18:06,600 --> 00:18:11,000
obviously it is feasible and 
just clear to to us now, but it 

342
00:18:11,000 --> 00:18:14,300
kind of, let's talk about. 
Let's talk about the history. 

343
00:18:14,300 --> 00:18:17,500
So basically, I mean if we kind 
of look back, the very first 

344
00:18:17,500 --> 00:18:21,300
kind of bridges. 
So to say, we had where, you 

345
00:18:21,300 --> 00:18:25,100
know, the the wrapped, Acid 
specific Bridges, right? 

346
00:18:25,100 --> 00:18:28,900
So things like rap Bitcoin and 
so on. 

347
00:18:29,700 --> 00:18:32,000
Well, technically the earliest 
ones were actually the atomic 

348
00:18:32,000 --> 00:18:34,900
swaps. 
So like, you know, BTC, LTC 

349
00:18:34,900 --> 00:18:38,700
Atomic swaps, things like that. 
Yeah, Fair Point. 

350
00:18:39,400 --> 00:18:42,300
The acid specific ones. 
Do you remember them taking off?

351
00:18:43,600 --> 00:18:47,300
Kinda, so like, technically 
shape-shift took off and 

352
00:18:47,300 --> 00:18:50,400
shape-shift is in theory, an 
atomic subsystem Atomic swap 

353
00:18:50,400 --> 00:18:53,100
like system. 
They do some other stuff. 

354
00:18:53,100 --> 00:18:55,700
But, you know, there, that was 
like, the idea behind it. 

355
00:18:56,600 --> 00:18:59,700
There were, of course, a lot of,
like, proposals around using 

356
00:18:59,700 --> 00:19:02,400
lightning that extending 
lightning to things like stellar

357
00:19:02,400 --> 00:19:05,700
and like Litecoin to do swaps 
there. 

358
00:19:06,600 --> 00:19:09,300
And then, and then, once the 
theorem came along the idea of 

359
00:19:09,300 --> 00:19:12,100
like, oh you can have like I 
think in theory when the theorem

360
00:19:12,100 --> 00:19:13,200
came along, that was like 
Windows. 

361
00:19:13,400 --> 00:19:15,100
The transformation because 
people started thinking about 

362
00:19:15,100 --> 00:19:20,000
like instead of just okay, let's
swap BTC for eith which has a 

363
00:19:20,008 --> 00:19:22,400
whole host of problems 
associated with things like, you

364
00:19:22,408 --> 00:19:26,300
know, front-running and Free 
Riders or free option. 

365
00:19:26,300 --> 00:19:30,300
Sorry, the instead the 
conversation turned to okay, how

366
00:19:30,300 --> 00:19:33,800
can we have a representation of 
BTC on ethereum that can then be

367
00:19:33,800 --> 00:19:38,100
used and that's I think part of 
when things got a lot more 

368
00:19:38,100 --> 00:19:41,100
interesting as well. 
I think the earliest projects 

369
00:19:41,100 --> 00:19:42,900
there were things like BTC 
relay. 

370
00:19:44,200 --> 00:19:47,700
And a couple of others. 
And like, it's pretty 

371
00:19:47,700 --> 00:19:50,000
interesting because like, the 
things that are really taken off

372
00:19:50,000 --> 00:19:53,100
her are like WBT, see, which is,
of course, like a fully 

373
00:19:53,100 --> 00:19:56,800
custodial BTC Bridge 
representation by B. 

374
00:19:56,800 --> 00:19:59,700
Co, I think a part of the reason
why a lot of these things didn't

375
00:19:59,700 --> 00:20:02,600
take off is because the need for
them wasn't actually as strong 

376
00:20:02,600 --> 00:20:06,400
at the time, you know, like the 
the idea was always like, okay. 

377
00:20:06,400 --> 00:20:11,000
Well you can swap BTC for 
something else like between 

378
00:20:11,000 --> 00:20:15,400
these like, you know account 
like In these like you T XO 

379
00:20:15,400 --> 00:20:19,200
style chains where there isn't 
any like broader functionality, 

380
00:20:19,200 --> 00:20:22,400
but the but that that 
functionality was always like 

381
00:20:22,400 --> 00:20:25,300
fully Encompass inside of a 
centralized exchange anyway, and

382
00:20:25,300 --> 00:20:28,200
so if you were unless like there
was like the novelty of like, 

383
00:20:28,200 --> 00:20:32,200
okay, I could do this in a trust
minimize way, but the the fact 

384
00:20:32,200 --> 00:20:34,900
that you could always use an 
exchange for it was also like 

385
00:20:35,400 --> 00:20:37,900
just made it so that there 
wasn't like a huge Improvement 

386
00:20:37,900 --> 00:20:42,400
against that to begin with. 
I think what's changed in recent

387
00:20:42,400 --> 00:20:46,800
times is that is the explosive 
growth of the ethereum ecosystem

388
00:20:46,800 --> 00:20:50,200
and like how that has resulted 
in this, like, fragmentation 

389
00:20:50,200 --> 00:20:52,100
across multiple, ethereum, like 
chains. 

390
00:20:53,000 --> 00:20:55,900
And, of course, now, moving to, 
like, non ethereum like chains, 

391
00:20:55,900 --> 00:20:58,500
like, Salona and like Stark 
where things like that as well, 

392
00:20:58,500 --> 00:21:02,400
but largely, it is all Evo 
compatible at the moment. 

393
00:21:02,700 --> 00:21:07,200
I think the, the like that has 
instigated this like question 

394
00:21:07,200 --> 00:21:11,000
of, okay. 
Well should Common protocols, 

395
00:21:11,200 --> 00:21:12,900
especially like Blue Chip. 
T5 protocols. 

396
00:21:12,900 --> 00:21:14,100
Should they just be deployed 
everywhere? 

397
00:21:14,100 --> 00:21:16,100
And I think most of them just 
said, yes, that should 

398
00:21:16,100 --> 00:21:18,400
absolutely happen. 
And once you do that now you 

399
00:21:18,400 --> 00:21:20,600
have this problem where it's 
like, okay, you have different 

400
00:21:20,600 --> 00:21:22,400
rates for these different 
particles of different chains. 

401
00:21:22,400 --> 00:21:24,800
Users now want to optimize the 
returns that they're getting 

402
00:21:25,100 --> 00:21:27,300
users, not want to use 
applications that run in many 

403
00:21:27,300 --> 00:21:29,200
ecosystems, all at once. 
And now you've created this, 

404
00:21:29,200 --> 00:21:31,800
like, huge problem around. 
Where do users go? 

405
00:21:31,800 --> 00:21:33,200
How to use, there's actually do 
that. 

406
00:21:34,500 --> 00:21:37,600
The other piece of it is also, 
which I think is actually a 

407
00:21:37,600 --> 00:21:41,700
little bit into unintuitive is 
that A lot of the conversation 

408
00:21:41,700 --> 00:21:46,400
at least like in the earliest 
days of this big bridging growth

409
00:21:46,400 --> 00:21:48,900
that happened, which is really 
it's like in like January 

410
00:21:48,900 --> 00:21:52,800
February of 2020. 
What we saw was that the vast 

411
00:21:52,800 --> 00:21:56,200
majority of people that were 
bridging, were not like ethereum

412
00:21:56,200 --> 00:21:59,000
L1 users. 
Surprisingly. 

413
00:21:59,500 --> 00:22:02,000
It was not people who are 
already using these chains. 

414
00:22:02,000 --> 00:22:04,300
It was new users coming into 
crypto. 

415
00:22:04,300 --> 00:22:08,100
Because, you know, there was 
just a massive growth of like 

416
00:22:08,100 --> 00:22:10,600
end users at the time. 
It was Users that were 

417
00:22:10,600 --> 00:22:14,200
onboarding finding that ethereum
L1 was too expensive for them. 

418
00:22:14,200 --> 00:22:17,600
And so they were onboarding 
directly into like BSC through 

419
00:22:17,600 --> 00:22:21,400
finance and then going to 
polygon or onboarding directly 

420
00:22:21,400 --> 00:22:23,700
into polygons and going to X Dy 
or something like that. 

421
00:22:23,800 --> 00:22:26,200
And so what we found was like 
and this is still, the case 

422
00:22:26,200 --> 00:22:29,300
actually is like the polygon B, 
SC noses. 

423
00:22:29,300 --> 00:22:34,300
Chain combo is actually by far, 
the most used set of chains that

424
00:22:34,300 --> 00:22:39,600
people bridge between and and, 
you know, even a lot of the No 

425
00:22:39,600 --> 00:22:40,800
Doubt. 
Operators in our Network 

426
00:22:40,800 --> 00:22:42,500
actually surprised by this 
because they're like, well we 

427
00:22:42,500 --> 00:22:44,300
would if we would have thought 
that tons of people would be 

428
00:22:44,300 --> 00:22:46,000
pitching in and have the 
ethereum but that actually 

429
00:22:46,000 --> 00:22:47,100
doesn't appear to be the case at
all. 

430
00:22:47,100 --> 00:22:49,800
It seems like mostly people that
have their funds on ethereum are

431
00:22:49,800 --> 00:22:52,800
just like not touching them as 
much as they possibly can. 

432
00:22:54,400 --> 00:22:57,000
Do you think that's just because
every time you touch them, you 

433
00:22:57,000 --> 00:23:00,600
incur horrendous gas fees or why
do you think that is? 

434
00:23:02,500 --> 00:23:04,500
I think that's a big part of it.
And I think the other part of it

435
00:23:04,500 --> 00:23:08,000
is also that like one of the 
things that made a theory of so 

436
00:23:08,000 --> 00:23:11,500
interested in an interesting and
exciting in the early days was 

437
00:23:11,500 --> 00:23:13,400
just that it was like, it was 
very experimental. 

438
00:23:13,400 --> 00:23:15,500
And like so there was a lot of 
room for people to go and just 

439
00:23:15,500 --> 00:23:17,800
build things and like, try new 
things and even if those things 

440
00:23:17,800 --> 00:23:21,200
were not gas optimized, or were 
really poorly builds or had like

441
00:23:21,200 --> 00:23:22,700
problems. 
It didn't really matter that 

442
00:23:22,700 --> 00:23:24,100
much right. 
People were just like playing 

443
00:23:24,100 --> 00:23:27,100
around. 
There is like a fun. 

444
00:23:28,100 --> 00:23:32,600
There's just so much like it is 
so much fun for developers 

445
00:23:32,800 --> 00:23:35,000
Builders to be able to like play
with things. 

446
00:23:35,000 --> 00:23:38,200
And I think that element was 
lost when when prices the price 

447
00:23:38,200 --> 00:23:40,500
of everything on ethereum, 
escalated significantly. 

448
00:23:41,400 --> 00:23:46,100
And what we found was that a lot
of the new developers that were 

449
00:23:46,100 --> 00:23:48,400
coming, the ecosystem that 
wanted to do the same thing that

450
00:23:48,400 --> 00:23:51,600
early developers did on E Theta,
1, which is just play, have a 

451
00:23:51,600 --> 00:23:53,500
good time, like, play with 
building things. 

452
00:23:53,900 --> 00:23:57,000
They all were doing this on 
polygon and BSE all of them. 

453
00:23:57,600 --> 00:24:00,200
And so, what we found was like, 
it was really just like a lot of

454
00:24:00,200 --> 00:24:03,100
completely new people. 
Like we most of the, the support

455
00:24:03,100 --> 00:24:05,100
request that we had, in our 
ecosystem, were actually 

456
00:24:05,100 --> 00:24:07,000
associated with. 
How do you speed up, 

457
00:24:07,000 --> 00:24:09,800
transactions in meta, masks? 
Not anything related to like 

458
00:24:09,800 --> 00:24:13,400
bridging itself. 
Yeah, super interesting. 

459
00:24:13,900 --> 00:24:18,100
When you think about like the 
different bridges that you can 

460
00:24:18,100 --> 00:24:21,100
have. 
Can we look at them kind of by 

461
00:24:21,700 --> 00:24:23,300
the thing that they Bridge, 
right? 

462
00:24:23,300 --> 00:24:25,800
I mean, it's basically there's, 
there's yes. 

463
00:24:25,800 --> 00:24:31,000
He 20 tokens. 
Yeah, 720 ones 1155. 

464
00:24:32,700 --> 00:24:36,000
There's message Bridges. 
So how do you think about that 

465
00:24:36,400 --> 00:24:40,700
just from, you know, zoology 
kind of point of view? 

466
00:24:40,800 --> 00:24:44,800
You. 
Yeah, yeah, that's a really good

467
00:24:44,800 --> 00:24:47,300
question. 
So the most General primitive is

468
00:24:47,300 --> 00:24:49,000
just like arbitrary message, 
passing, right? 

469
00:24:49,000 --> 00:24:52,100
It's like how do I get some data
from one chain to another 

470
00:24:52,100 --> 00:24:54,900
change? 
Ideally, trust this lie, which 

471
00:24:54,900 --> 00:24:57,300
basically means ideally without 
introducing additional trust 

472
00:24:57,300 --> 00:25:00,200
assumptions against those that 
exist on the underlying chains. 

473
00:25:00,800 --> 00:25:03,200
And of course, that is an 
extremely difficult thing to do.

474
00:25:03,200 --> 00:25:05,400
And like there are really very 
few. 

475
00:25:05,400 --> 00:25:07,900
If or perhaps no constructions 
that fully achieve this. 

476
00:25:09,000 --> 00:25:13,500
But because that is like the 
base layer you do sort of End up

477
00:25:13,500 --> 00:25:16,400
in a situation. 
Unless and I want to carve out 

478
00:25:16,400 --> 00:25:18,500
an exception here, which is 
atomic swaps which are like a, 

479
00:25:18,500 --> 00:25:21,600
very special case scenario, but 
for anything else, the idea is 

480
00:25:21,600 --> 00:25:24,100
like, you sort of need to have 
this ability to like pass around

481
00:25:24,100 --> 00:25:26,400
data to begin with before you 
can do anything else. 

482
00:25:26,700 --> 00:25:28,400
Now on top of that. 
So that's, that's kind of like 

483
00:25:28,400 --> 00:25:30,500
the message passing layer. 
Now on top of that, what you 

484
00:25:30,500 --> 00:25:35,000
will use usually have is like, 
you know, other layers for other

485
00:25:35,000 --> 00:25:37,400
kinds of bridging. 
So, you know, you could allow 

486
00:25:37,400 --> 00:25:41,600
for some of wrapper around the 
arbitrary message passing that 

487
00:25:41,600 --> 00:25:43,900
allows you to Mint and burn and 
if Is it now that becomes an 

488
00:25:43,900 --> 00:25:45,800
entity Bridge? 
You can allow doing the same 

489
00:25:45,800 --> 00:25:48,600
thing with your see 20s, and now
that becomes like a token bridge

490
00:25:48,800 --> 00:25:51,300
and that specifically is a token
bridge that allows you to like 

491
00:25:51,300 --> 00:25:54,100
minted burn wrapped 
representations of that token. 

492
00:25:54,500 --> 00:25:59,000
And then and then the last piece
that kind of like potentially 

493
00:25:59,000 --> 00:26:01,600
sits on top of all of this is 
like the liquidity piece. 

494
00:26:01,600 --> 00:26:04,700
So and this is this is a big 
part of what connects does. 

495
00:26:04,700 --> 00:26:07,300
And, you know, we'll talk a 
little bit about like connect 

496
00:26:07,300 --> 00:26:10,300
stand and Nomad which is that 
like arbitrary message passing 

497
00:26:10,400 --> 00:26:15,000
Network that we sit on top of. 
But You know, liquidity, 

498
00:26:15,000 --> 00:26:18,800
specifically refers to, how do 
you ensure that the user gets 

499
00:26:18,800 --> 00:26:23,700
the correct asset on the like 
that they need on a given chain,

500
00:26:24,300 --> 00:26:27,700
especially given that in many 
cases that correct asset may be 

501
00:26:27,700 --> 00:26:30,300
different than the minted 
representation that you create 

502
00:26:30,300 --> 00:26:34,500
through an arbitrary message, 
passing bridge and and that is 

503
00:26:34,500 --> 00:26:36,900
something that requires, you 
know, things like liquidity 

504
00:26:36,900 --> 00:26:41,800
pools in order to make sure that
you bootstrap liquidity in the 

505
00:26:41,800 --> 00:26:44,200
asset that you need to lie. 
Transmitted to the user. 

506
00:26:45,800 --> 00:26:49,300
That's a lot to unpack your so 
maybe just rewind just to make 

507
00:26:49,300 --> 00:26:52,900
sure this is absolutely clear. 
So basically when I take an acid

508
00:26:52,900 --> 00:27:00,200
say from from polygon to be a 
sea via specific bridge, that 

509
00:27:00,200 --> 00:27:04,400
that acid that is de facto 
minted. 

510
00:27:04,400 --> 00:27:13,600
At that point in time, on BSE is
basically, is that acid the said

511
00:27:13,600 --> 00:27:18,500
that acid underscore The bridge 
that it came over and it's not 

512
00:27:18,500 --> 00:27:23,600
fungible with that asset that 
lives on that chain natively or 

513
00:27:23,600 --> 00:27:26,500
came by means of another Bridge,
right? 

514
00:27:28,200 --> 00:27:30,100
Exactly. 
So, the problem here is 

515
00:27:30,100 --> 00:27:34,900
basically like, when you have an
acid representation on a given 

516
00:27:34,900 --> 00:27:40,100
chain, if it's the canonical 
asset, what makes a very first 

517
00:27:40,100 --> 00:27:41,700
of all, there's this bigger 
question of like, what makes 

518
00:27:41,700 --> 00:27:44,300
this asset, the canonical asset.
Generally what we say is like, 

519
00:27:44,300 --> 00:27:46,600
okay, it's the most widely 
adopted as it may be. 

520
00:27:46,600 --> 00:27:49,000
It may be like in polygons case.
It may be the acid that's coming

521
00:27:49,000 --> 00:27:51,600
over the polygon POS bridge. 
In other cases. 

522
00:27:51,600 --> 00:27:53,300
It may just be the asset that 
happened to get the most 

523
00:27:53,300 --> 00:27:54,900
traction. 
So like on Avalanches like u.s. 

524
00:27:54,900 --> 00:27:58,700
Dce which is like the Of USD. 
See that everybody. 

525
00:27:58,700 --> 00:28:01,400
Everybody just started using and
now it's the canonical one. 

526
00:28:02,100 --> 00:28:04,300
The second piece. 
There is a second question. 

527
00:28:04,300 --> 00:28:08,100
There is like, who actually owns
the authority, the the 

528
00:28:08,100 --> 00:28:11,300
permissions to create more of 
this canonical representation. 

529
00:28:12,400 --> 00:28:16,700
So typically this will be like 
in polygons case will be like 

530
00:28:16,700 --> 00:28:19,500
the the like chain, sponsor 
Bridge, like the polygon POS 

531
00:28:19,500 --> 00:28:23,000
bridge and avalanches the 
Avalanche bridge in Roll-Ups. 

532
00:28:23,000 --> 00:28:25,200
It'll be the role of bridge. 
And so it Roll-Ups actually have

533
00:28:25,200 --> 00:28:26,700
like an easier time with this 
because they already have a 

534
00:28:26,708 --> 00:28:27,600
trust minimize. 
Bridge. 

535
00:28:27,600 --> 00:28:29,900
That is the canonical one and 
nobody can ever dispute that. 

536
00:28:30,400 --> 00:28:36,200
But if you if you don't have one
dedicated bridge, that is meant 

537
00:28:36,200 --> 00:28:38,000
it minting like a canonical 
token. 

538
00:28:38,000 --> 00:28:40,100
You don't have necessarily 
economical token, begin with 

539
00:28:40,100 --> 00:28:41,200
things, get a lot more 
confusing. 

540
00:28:41,600 --> 00:28:44,500
So what happens if, for example,
you have another Bridge, like no

541
00:28:44,500 --> 00:28:47,600
Medford since that, it's like 
minting and acid on polygon. 

542
00:28:48,100 --> 00:28:52,500
The minted acid on like that 
Nomad will likely not have the 

543
00:28:52,500 --> 00:28:57,300
permissions to increase the 
supply of the polygon POS. 

544
00:28:57,400 --> 00:29:00,300
Representation. 
And so instead what Nomad would 

545
00:29:00,300 --> 00:29:02,900
do is they would have to create 
their own representation, which 

546
00:29:02,900 --> 00:29:06,500
is a pointer to wherever this 
tokens were first locked on 

547
00:29:06,500 --> 00:29:11,300
whatever chain. 
And, and now you have an asset 

548
00:29:11,300 --> 00:29:13,900
that is Nomad wrapped polygon 
u.s. 

549
00:29:13,900 --> 00:29:16,000
DC and then you have another 
asset that is polygon. 

550
00:29:16,000 --> 00:29:18,700
POS USD. 
See the polygon POS you see, you

551
00:29:18,700 --> 00:29:21,800
SDC is the canonical one because
it is used widely across all of 

552
00:29:21,800 --> 00:29:23,700
the default applications on 
polygon. 

553
00:29:24,400 --> 00:29:27,000
And so as a user you now have 
this like user experience 

554
00:29:27,000 --> 00:29:29,000
problem. 
Of, I have this asset, how do I 

555
00:29:29,000 --> 00:29:31,200
get to the correct asset? 
Because I can't actually use 

556
00:29:31,200 --> 00:29:35,200
this asset anyway. 
Sounds like mess. 

557
00:29:35,500 --> 00:29:40,500
It's definitely a huge headache.
How do you how do you go about 

558
00:29:40,500 --> 00:29:45,000
it? 
Yeah, so what we do is wherever 

559
00:29:45,000 --> 00:29:47,700
possible, we try to swap the 
user into their like the 

560
00:29:47,700 --> 00:29:49,700
canonical asset, the most widely
used acid. 

561
00:29:50,900 --> 00:29:54,200
And so this kind of gets into a 
little bit of the technical 

562
00:29:54,200 --> 00:29:56,900
details of like how Nomad works 
and things like that and how 

563
00:29:56,900 --> 00:29:59,300
connects fits into it which you 
can definitely get into in more 

564
00:29:59,300 --> 00:30:03,400
depth, but at a high level with 
how connects Works currently, we

565
00:30:03,400 --> 00:30:06,100
just basically swap into 
liquidity pools of whatever 

566
00:30:06,100 --> 00:30:09,100
asset is like the most widely 
used and in the future, what 

567
00:30:09,100 --> 00:30:12,800
we'll be doing is we would use 
so rather, Then swapping 

568
00:30:12,800 --> 00:30:16,000
directly between chains just as 
a mechanism to improve the 

569
00:30:16,000 --> 00:30:18,900
usability of connects to end the
the experience of running a note

570
00:30:18,900 --> 00:30:22,300
in Connect. 
We will mint a nomad 

571
00:30:22,300 --> 00:30:25,300
representative asset that goes 
across chains. 

572
00:30:26,200 --> 00:30:31,000
This will be like the sort of 
default asset that is used in 

573
00:30:31,000 --> 00:30:33,600
our system. 
But then at at the the exit 

574
00:30:33,600 --> 00:30:36,100
point when the user is about to 
receive their liquidity, that 

575
00:30:36,100 --> 00:30:39,800
will be swapped for some local 
asset if needed using a stable 

576
00:30:39,800 --> 00:30:42,400
swap. 
So the construction Here is a 

577
00:30:42,400 --> 00:30:45,400
little bit similar to something 
like hop where you know, hop, 

578
00:30:45,400 --> 00:30:48,700
basically utilizes the arbitrary
messaging bridges on Roll-Ups to

579
00:30:48,700 --> 00:30:51,300
create H tokens, which are their
own representation. 

580
00:30:51,600 --> 00:30:55,700
And then they swap them at the 
end into like the the the 

581
00:30:55,700 --> 00:31:00,800
Roll-Ups token if needed. 
How do you make sure you have 

582
00:31:00,800 --> 00:31:05,600
sufficient liquidity? 
When people try to move across 

583
00:31:06,000 --> 00:31:09,600
large sums of money or even 
tokens that you have. 

584
00:31:09,700 --> 00:31:12,000
I mean you need to unboard 
tokens, right? 

585
00:31:12,000 --> 00:31:14,400
So you can't offer this for just
any token. 

586
00:31:14,400 --> 00:31:17,000
You kind of need to know which 
tokens are coming in advance. 

587
00:31:17,300 --> 00:31:19,400
Yes. 
Yeah, that's definitely a 

588
00:31:19,408 --> 00:31:22,200
challenge. 
I think this is something that 

589
00:31:22,200 --> 00:31:25,700
we're still trying to understand
the best sort of user experience

590
00:31:25,700 --> 00:31:29,000
around its and developer. 
Experience around because it's 

591
00:31:29,000 --> 00:31:32,100
complicated and it seems to 
really change based on use case.

592
00:31:33,400 --> 00:31:35,600
What we have right now is the 
ability to set like slipper 

593
00:31:35,600 --> 00:31:38,300
tolerance in these transactions.
So, you can, you can at least 

594
00:31:38,300 --> 00:31:40,500
like be sure. 
That as a user, you're not going

595
00:31:40,500 --> 00:31:42,700
to get completely wrecked by so 
veg, because there wasn't enough

596
00:31:42,700 --> 00:31:45,700
liquidity. 
And then in Failure modes, what 

597
00:31:45,700 --> 00:31:51,700
we do is we just like, allow the
developer basically like exit 

598
00:31:51,700 --> 00:31:54,800
the users fobs onto, is it funds
onto like a given chain and then

599
00:31:54,800 --> 00:31:57,200
have the developer actually be 
responsible for figuring out how

600
00:31:57,200 --> 00:32:00,000
to handle. 
Our case themselves and over the

601
00:32:00,008 --> 00:32:02,600
long term. 
The idea is like, we're going to

602
00:32:02,800 --> 00:32:05,400
try to build a better, taxonomy 
of use cases. 

603
00:32:05,400 --> 00:32:07,400
And, and the way that those are 
handled from a narrow 

604
00:32:07,400 --> 00:32:10,700
perspective or from a like 
failure mode perspective, and 

605
00:32:10,700 --> 00:32:14,000
then find like, default 
mechanisms to handle those 

606
00:32:14,000 --> 00:32:16,700
failure modes, but at this 
stage, it's like early enough. 

607
00:32:16,700 --> 00:32:19,500
It's too early for us to really 
be able to say definitively 

608
00:32:19,500 --> 00:32:23,200
that, like every kind of use 
case of X-Type needs to be 

609
00:32:23,200 --> 00:32:25,800
handled in this way because we 
just, we just don't know yet. 

610
00:32:26,800 --> 00:32:30,100
Yeah, I mean the complexity 
behind kind of having all these 

611
00:32:30,100 --> 00:32:33,500
different flavors of more or 
less the same acid. 

612
00:32:34,400 --> 00:32:37,300
This is actually really 
mind-boggling. 

613
00:32:37,900 --> 00:32:40,800
So in a way you kind of need 
someone who behind behind the 

614
00:32:40,800 --> 00:32:42,300
scenes. 
I mean, it's kind of like having

615
00:32:42,300 --> 00:32:45,200
this this massive ball of yarn, 
right. 

616
00:32:45,200 --> 00:32:48,200
And someone behind the scenes 
kind of needs to, you know, 

617
00:32:48,200 --> 00:32:51,300
continue. 
No perpetually kind of order it 

618
00:32:51,300 --> 00:32:54,700
and unwind it and make sure that
kind of it doesn't tangle too 

619
00:32:54,700 --> 00:32:57,100
badly and it actually gets Our 
stew. 

620
00:32:57,100 --> 00:32:59,300
So like on chains or you know, 
there's there's been like 

621
00:32:59,300 --> 00:33:03,100
several waves of chain launches 
in a lot of the earlier chains. 

622
00:33:03,100 --> 00:33:07,600
Like polygon B, SC Avalanche, 
there were already like chain 

623
00:33:07,600 --> 00:33:11,000
built canonical Bridges, right? 
And like the chains themselves 

624
00:33:11,000 --> 00:33:15,700
were like, you know, had lead 
time to have those canonical 

625
00:33:15,700 --> 00:33:18,100
Bridges. 
Be kind of publicly used before 

626
00:33:18,300 --> 00:33:20,700
other Bridges came and started 
like building hot, creating 

627
00:33:20,700 --> 00:33:23,300
their own like representative 
assets, but a lot of the newer 

628
00:33:23,300 --> 00:33:26,400
chains that have launched in 
this like second wave of L1. 

629
00:33:26,500 --> 00:33:32,400
On like L1 releases have things 
like Moonbeam and at most things

630
00:33:32,400 --> 00:33:34,600
are a lot more messy. 
So like for example, on would be

631
00:33:34,600 --> 00:33:37,500
monogamous, connects to no 
matter, technically the default 

632
00:33:37,500 --> 00:33:39,100
Bridge. 
We're technically the official 

633
00:33:39,200 --> 00:33:42,400
officially supported bridge, but
that, that hasn't really meant 

634
00:33:42,400 --> 00:33:45,000
anything because like, there's 
these are personal assistants. 

635
00:33:45,000 --> 00:33:48,000
It's possible for a lot of other
projects to come a deployed 

636
00:33:48,000 --> 00:33:49,700
obvious systems, and it's 
actually a good thing if they 

637
00:33:49,700 --> 00:33:52,700
do. 
But what that means is like now 

638
00:33:52,700 --> 00:33:55,800
on Moonbeam, for instance. 
There are also, like, multi 

639
00:33:55,800 --> 00:33:57,900
chain. 
Like representative tokens. 

640
00:33:57,900 --> 00:34:00,500
So, any tokens there are seller 
represented folk ins. 

641
00:34:00,500 --> 00:34:03,000
There are sit-ups representative
tokens Wormhole represent of 

642
00:34:03,000 --> 00:34:06,500
tokens. 
And, and now it's an extremely 

643
00:34:06,500 --> 00:34:09,400
confusing problem for the user. 
And there's, no, there's no, you

644
00:34:09,400 --> 00:34:12,699
know, even if the Moonbeam team 
says, okay, XYZ tokens are the 

645
00:34:12,699 --> 00:34:15,800
canonical representation. 
It ultimately isn't even really 

646
00:34:15,800 --> 00:34:20,000
up to them. 
Like, they, it really is up to 

647
00:34:20,900 --> 00:34:23,500
the network effects of the 
applications that are running on

648
00:34:23,500 --> 00:34:27,900
top of this in this ecosystem. 
So, We have yet to figure out a 

649
00:34:27,900 --> 00:34:30,500
good way to solve this mess. 
There are definitely a lot of 

650
00:34:30,500 --> 00:34:33,100
proposals out there to do things
like, allow multiple Bridges to 

651
00:34:33,107 --> 00:34:36,300
meant the same token, but then 
that just increases risk 

652
00:34:36,300 --> 00:34:37,800
massively across the entire 
space. 

653
00:34:37,800 --> 00:34:40,800
So, we're generally pushing back
against things like that. 

654
00:34:41,000 --> 00:34:43,900
But yeah, it's a very big, very 
hairy problem that at the moment

655
00:34:43,900 --> 00:34:49,300
doesn't really have a solution. 
I want to talk about security 

656
00:34:49,800 --> 00:34:53,900
little bit later, but kind of, 
let's let's talk about this for 

657
00:34:53,900 --> 00:34:56,199
a little while longer. 
So I mean, basically we've seen 

658
00:34:56,500 --> 00:35:00,300
this in a similar version of 
this problem across Texas, 

659
00:35:00,400 --> 00:35:02,500
right? 
So basically, the Arbitrage 

660
00:35:02,500 --> 00:35:05,600
opportunities that you have 
between different dex's that 

661
00:35:05,600 --> 00:35:08,300
mean, and the way that the 
market has solved that is by 

662
00:35:08,300 --> 00:35:14,800
kind of having market makers, 
who kind of, I mean, it in a 

663
00:35:14,800 --> 00:35:20,600
negative reading their Jazz. 
But in positive reading kind of,

664
00:35:21,100 --> 00:35:24,700
they make the market more 
efficient, because you can kind 

665
00:35:24,700 --> 00:35:28,400
of trade across because the 
prize of different assets. 

666
00:35:28,400 --> 00:35:32,100
Kind of normalizes across 
different textures, right? 

667
00:35:32,300 --> 00:35:37,300
Did you think I'm having such 
radically decentralized approach

668
00:35:38,100 --> 00:35:42,000
to the bridge problem would be a
good solution? 

669
00:35:42,000 --> 00:35:43,400
Or do you think it has 
drawbacks? 

670
00:35:45,200 --> 00:35:49,000
Yeah, so basically the question 
is like is it a good idea to 

671
00:35:49,000 --> 00:35:53,300
just offload The Bouncing 
between these different kind of 

672
00:35:53,300 --> 00:35:56,400
bridge options and moving 
basically moving between these 

673
00:35:56,400 --> 00:35:59,100
different assets to just the 
credit providers in market 

674
00:35:59,100 --> 00:36:02,400
makers. 
Who can ensure that users will 

675
00:36:02,400 --> 00:36:05,400
get the right asset. 
And like as a result of that we 

676
00:36:06,400 --> 00:36:10,100
we can still maintain like a 
good user experience while 

677
00:36:10,100 --> 00:36:12,400
having multiple charges. 
I think so. 

678
00:36:12,400 --> 00:36:15,600
I mean, I think that's The 
whether or not it's a good 

679
00:36:15,600 --> 00:36:19,000
solution, which I think it is. 
I mean, I think it is in the 

680
00:36:19,000 --> 00:36:21,600
sense that like, it's there 
really is no other option. 

681
00:36:22,700 --> 00:36:25,100
So I do think that like we are 
headed in that direction 

682
00:36:25,100 --> 00:36:29,000
regardless, which is that like 
there were likely be a lot of 

683
00:36:29,300 --> 00:36:31,500
stable swaps and all these on 
all of these changes that will 

684
00:36:31,500 --> 00:36:33,700
allow you to move between these 
efforts representative assets 

685
00:36:33,700 --> 00:36:38,300
and I think, eventually 
long-term all of these projects 

686
00:36:38,300 --> 00:36:40,700
will eventually just like plug 
directly into the stable stock 

687
00:36:40,700 --> 00:36:43,100
so that the user is just getting
the right asset on a given 

688
00:36:43,100 --> 00:36:45,400
chain. 
But I think I think that core 

689
00:36:45,400 --> 00:36:47,500
problem of like, how do you and 
determine what the right asset 

690
00:36:47,500 --> 00:36:50,800
is is just at the moment just a 
huge mess. 

691
00:36:51,400 --> 00:36:54,400
It's just like an open field 
right now. 

692
00:36:54,400 --> 00:36:59,600
We're like, you know, we and 
other Bridges or actively like, 

693
00:37:00,100 --> 00:37:03,700
you know, chains like Moonbeam 
are actively Battlegrounds where

694
00:37:04,100 --> 00:37:06,800
we another bridges are fighting 
for market, share and try to 

695
00:37:06,808 --> 00:37:11,200
work towards, having our version
be like the canonical 

696
00:37:11,200 --> 00:37:14,200
representation. 
And of course like on our And 

697
00:37:14,200 --> 00:37:15,600
it's not the worst situation the
world. 

698
00:37:15,600 --> 00:37:17,800
If that doesn't happen because 
we can, we can just fly for 

699
00:37:17,800 --> 00:37:20,600
swapping into the right one. 
But at the same time, you know, 

700
00:37:20,600 --> 00:37:24,200
if our whole model is we want to
make sure that users are like, 

701
00:37:24,200 --> 00:37:27,100
I'm a big part of what we care 
about is like a globally, trust 

702
00:37:27,100 --> 00:37:30,600
minimized option, you know, we 
really feel strongly that like 

703
00:37:31,200 --> 00:37:34,400
the inherent risks associated 
with bridging. 

704
00:37:34,400 --> 00:37:36,700
And with, like cross chain, 
interoperability are much higher

705
00:37:36,700 --> 00:37:38,300
than even just like change 
themselves. 

706
00:37:39,100 --> 00:37:41,000
There are systemic problems 
associated with that. 

707
00:37:41,300 --> 00:37:43,900
And a lot of the systemic 
problems are also arise from. 

708
00:37:44,000 --> 00:37:48,100
Um, like potential economic 
failures, right? 

709
00:37:48,100 --> 00:37:50,700
Not just, you know, the bridge 
gets hacked or there's an 

710
00:37:50,700 --> 00:37:53,900
implementation baggage or like a
like a security vulnerability, 

711
00:37:53,900 --> 00:37:59,700
but instead there is economic 
risk where markets or like the 

712
00:37:59,700 --> 00:38:02,100
the economics of bridges could 
be manipulated to attack them. 

713
00:38:02,600 --> 00:38:04,600
And this is simply this is 
basically what happened, you 

714
00:38:04,600 --> 00:38:08,800
know with Terror for instance 
where you know markets Tara 

715
00:38:08,800 --> 00:38:11,500
markets were manipulated to 
exploit a vulnerability economic

716
00:38:11,500 --> 00:38:13,900
vulnerability in the way in 
Tara's the entire. 

717
00:38:14,300 --> 00:38:16,700
The UST system. 
And and the idea. 

718
00:38:16,700 --> 00:38:21,000
Is that like, Long term. 
If we want this ecosystem to be 

719
00:38:21,000 --> 00:38:23,000
sustainable. 
We have to build systems. 

720
00:38:23,000 --> 00:38:26,600
That remain V invulnerable to 
those kinds of attacks, you 

721
00:38:26,600 --> 00:38:31,500
know, because those kinds of 
attacks will happen either from,

722
00:38:31,700 --> 00:38:36,400
you know, theoretically Shady 
while Street organizations or 

723
00:38:36,400 --> 00:38:39,800
perhaps governments or perhaps 
large scale, corporations or 

724
00:38:39,800 --> 00:38:41,900
billionaires that want to find 
ways to extract value. 

725
00:38:43,000 --> 00:38:46,200
And so, my concern is like, I 
don't, you know, on the one 

726
00:38:46,200 --> 00:38:48,800
hand. 
It would be it doesn't really 

727
00:38:48,800 --> 00:38:52,200
matter that much if we end up in
a world where like, you know, 

728
00:38:52,200 --> 00:38:55,200
you're utilizing Nomad to go 
across Nomad and connects to go 

729
00:38:55,200 --> 00:38:57,400
across chains. 
And then at the, at the, at the 

730
00:38:57,400 --> 00:39:00,300
exit, we're swapping into like 
any us DC or something like 

731
00:39:00,300 --> 00:39:03,100
that. 
The, but at the same time that 

732
00:39:03,100 --> 00:39:06,200
of course means that users are 
now holding any us DC in their 

733
00:39:06,200 --> 00:39:07,500
wallets. 
And so now they are still 

734
00:39:07,500 --> 00:39:10,100
subject, always permanently 
subject to the risk of of any 

735
00:39:10,100 --> 00:39:16,300
swap or multi chain. 
Yeah, I have so many questions 

736
00:39:16,300 --> 00:39:19,200
about security and basically how
security guarantees kind of 

737
00:39:19,200 --> 00:39:23,400
transfer from, but I kind of, I 
want to save them because first,

738
00:39:23,400 --> 00:39:29,300
I want to hear about Nomad and 
connects in basically, who does 

739
00:39:29,300 --> 00:39:33,200
what and how they interplay and 
how this partnership came about.

740
00:39:34,600 --> 00:39:36,500
S start with how the partnership
came about. 

741
00:39:37,300 --> 00:39:40,200
So we you know, we've been 
researchers in the space for a 

742
00:39:40,207 --> 00:39:43,600
really long time working with a 
lot of like key research teams 

743
00:39:43,600 --> 00:39:45,900
that are out there. 
So, you know, we work super 

744
00:39:45,900 --> 00:39:48,800
closely with like and we have 
word super closely with like, 

745
00:39:48,900 --> 00:39:50,800
you know, the optimism. 
Father is the Arbiter Founders 

746
00:39:50,800 --> 00:39:52,500
you can say about etcetera, etc,
etc. 

747
00:39:53,400 --> 00:39:56,500
And and that I think a lot of 
people don't realize that that 

748
00:39:56,500 --> 00:39:57,800
Community is actually a really 
small. 

749
00:39:57,800 --> 00:39:59,600
So like even though it seems 
like a lot of these projects are

750
00:39:59,607 --> 00:40:01,700
competitive with one another, we
all like share notes. 

751
00:40:01,700 --> 00:40:03,200
We all talk to each other 
constantly. 

752
00:40:03,900 --> 00:40:05,800
We all present at the same 
conferences, research 

753
00:40:05,800 --> 00:40:10,700
conferences because ultimately, 
you know, there is like, of 

754
00:40:10,700 --> 00:40:13,100
course, there is competition, 
but at the same time like we 

755
00:40:13,100 --> 00:40:15,600
sort of all recognize that the 
market for this is so massive 

756
00:40:15,600 --> 00:40:17,800
that at this stage. 
It's like pretty positive some 

757
00:40:18,900 --> 00:40:22,900
in, for us, you know, early on, 
one of our key advisors around 

758
00:40:22,900 --> 00:40:25,300
this interoperability piece, was
always James press, which 

759
00:40:25,600 --> 00:40:28,500
because he is just like one of 
the foremost people who has been

760
00:40:28,500 --> 00:40:31,900
thinking about bridging for 
many, many years longer than 

761
00:40:31,900 --> 00:40:34,000
anyone else that has a In the 
space. 

762
00:40:34,400 --> 00:40:38,700
Yeah, we had him on for some 
probably like four years ago or 

763
00:40:38,700 --> 00:40:40,300
so. 
And basically he had just 

764
00:40:40,300 --> 00:40:44,700
launched the the Bitcoin 
etherium auction. 

765
00:40:45,200 --> 00:40:48,900
James is awesome. 
And he's been thinking about 

766
00:40:48,900 --> 00:40:52,500
this like very very deeply for 
quite a long time for a good 

767
00:40:52,500 --> 00:40:56,500
reason and he has like pretty 
nuanced opinions on this stuff. 

768
00:40:56,500 --> 00:40:58,300
It's not you know, he 
understands that there are like 

769
00:40:58,300 --> 00:41:00,300
a very big trade-offs and 
understands that there are such 

770
00:41:00,300 --> 00:41:03,300
like a there is room for 
multiple different kinds of 

771
00:41:03,400 --> 00:41:07,400
Solutions out there. 
And so, I think a lot of, a lot 

772
00:41:07,400 --> 00:41:09,300
of the reason that we ended up 
working with Nomad was just 

773
00:41:09,300 --> 00:41:11,200
because of our very deep 
relationship with James. 

774
00:41:11,800 --> 00:41:16,500
And and and as a result of that,
also like the the very strong 

775
00:41:16,500 --> 00:41:18,800
cultural similarities between 
the connects team and the 

776
00:41:18,800 --> 00:41:22,500
normative which is that like, 
we're all just very kind of. 

777
00:41:23,500 --> 00:41:27,900
We are all people that have been
very, very focused on like 

778
00:41:27,900 --> 00:41:30,100
producing value in the Space 
Center around research and 

779
00:41:30,100 --> 00:41:32,800
around like building the 
sustainable public goods that 

780
00:41:32,800 --> 00:41:34,600
are actually charged. 
Mize is actually trying to do 

781
00:41:34,600 --> 00:41:38,200
something good. 
And we are also all both like 

782
00:41:38,200 --> 00:41:41,800
teams that care about the same 
kinds of things that like have 

783
00:41:41,800 --> 00:41:44,600
the same kinds of attitudes 
towards like building 

784
00:41:44,600 --> 00:41:48,400
communities and and like, being 
sustainable organizations, but 

785
00:41:48,400 --> 00:41:50,600
then beyond that, I think I 
think there's also just there 

786
00:41:50,600 --> 00:41:52,000
was just like a natural fit as 
well. 

787
00:41:52,000 --> 00:41:57,200
So like we what we found was 
that over time, you know, 

788
00:41:57,400 --> 00:42:00,500
connects historically have been 
focused on a topic swaps because

789
00:42:00,500 --> 00:42:02,500
we were really interested in 
just solving the Like Liquor DPS

790
00:42:02,500 --> 00:42:04,100
first before it's I need other 
things. 

791
00:42:04,800 --> 00:42:06,600
Now, of course, our are we 
really think? 

792
00:42:06,600 --> 00:42:08,700
Do you think that the Holy Grail
is to be able to do any kind of 

793
00:42:08,707 --> 00:42:10,700
arbitrary messaging and also 
have liquidy built-in? 

794
00:42:11,100 --> 00:42:13,200
And and that was something that 
we were struggling for a while 

795
00:42:13,200 --> 00:42:16,200
because struggling with for a 
while because what we found was 

796
00:42:16,200 --> 00:42:19,500
that there was just no really 
good way to do that out there. 

797
00:42:19,800 --> 00:42:22,200
And this is this kind of gets 
into like the interoperability 

798
00:42:22,200 --> 00:42:26,000
trilemma piece which which which
I wrote which which which 

799
00:42:26,000 --> 00:42:30,100
basically breaks down the 
trade-off space around Bridges 

800
00:42:30,200 --> 00:42:34,100
and it shows that it's actually 
really difficult to have Any 

801
00:42:34,100 --> 00:42:37,900
system that simultaneously is 
Deployable too many different 

802
00:42:37,900 --> 00:42:41,300
chains is supports arbitrary 
message passing through, is 

803
00:42:41,308 --> 00:42:43,500
generalized and, and then also 
is trust minimized. 

804
00:42:43,800 --> 00:42:45,800
And as we were looking at, in 
this space, what we found was 

805
00:42:45,800 --> 00:42:50,000
like, we wanted to find create 
some sort of either create or 

806
00:42:50,000 --> 00:42:52,100
work with some sort of mechanism
to do this and the only 

807
00:42:52,100 --> 00:42:54,300
mechanism that we found that 
actually had acceptable trade 

808
00:42:54,300 --> 00:42:58,200
offs was Nova. 
So we we became involved pretty 

809
00:42:58,200 --> 00:43:01,100
early, you know, we were been 
were collaborating closely with 

810
00:43:01,100 --> 00:43:04,300
the team for quite a long time. 
And at this stage, the way that 

811
00:43:04,300 --> 00:43:07,500
the relationship works is that 
like we sort of think of 

812
00:43:07,500 --> 00:43:09,500
ourselves, as as the shared 
stack. 

813
00:43:09,500 --> 00:43:10,700
We actually call it. 
The module interoperability 

814
00:43:10,700 --> 00:43:15,600
stuck, which is the species that
like it is impossible similar to

815
00:43:15,600 --> 00:43:19,100
like the scalability. 
Trilemma and modular block 

816
00:43:19,100 --> 00:43:22,200
chains is a solution to the 
scalability trauma there is 

817
00:43:22,200 --> 00:43:24,700
because there is this 
interoperability trade-off 

818
00:43:24,700 --> 00:43:27,900
space. 
It is not possible for us to 

819
00:43:27,900 --> 00:43:30,600
just have a single solution that
solves, everything associated 

820
00:43:30,600 --> 00:43:34,000
with bridging and interrupt. 
Instead, we need to Find ways to

821
00:43:34,000 --> 00:43:36,900
split out the responsibilities 
and build a stack of protocols. 

822
00:43:37,500 --> 00:43:41,100
That can work with each other, 
in a limited way, with with kind

823
00:43:41,100 --> 00:43:43,300
of like fixed interfaces and 
delete fixed delineation of 

824
00:43:43,300 --> 00:43:46,800
responsibilities. 
That could then provide a 

825
00:43:46,800 --> 00:43:50,900
solution that actually is as 
close to Ideal as possible. 

826
00:43:51,900 --> 00:43:55,100
So the way that the the 
delineation of responsibilities 

827
00:43:55,100 --> 00:43:57,400
works, is that Nomad provides 
this, like base layer of 

828
00:43:57,400 --> 00:44:00,100
message? 
Passing Nomad allows you to do, 

829
00:44:00,600 --> 00:44:03,200
generalized, communication 
between blockchains. 

830
00:44:03,300 --> 00:44:08,400
Ends with very reasonable Fair, 
very trust minimized assumptions

831
00:44:08,800 --> 00:44:12,900
like security assumptions and 
and then but with the trade-off 

832
00:44:12,900 --> 00:44:17,000
of needing 30 minutes to do to 
pass messages between trains and

833
00:44:17,000 --> 00:44:19,500
that 30 minutes is the amount of
time needed to like, instigate a

834
00:44:19,500 --> 00:44:23,700
dispute, if, if something if 
fraud occurs within Nomad, so 

835
00:44:23,700 --> 00:44:26,800
that's because it's it's it's 
inherently optimistic. 

836
00:44:26,800 --> 00:44:29,800
That's why you need the okay. 
So basically exactly so, like, 

837
00:44:29,800 --> 00:44:34,200
Nomad in Nomads model, the 
assumption is Not like in 

838
00:44:34,200 --> 00:44:37,100
something like I see where you 
know, an IBC you have, what is 

839
00:44:37,100 --> 00:44:40,200
called a validity proof where 
you have one chain, like the 

840
00:44:40,200 --> 00:44:42,900
validators of one chain are like
verifying the consensus of 

841
00:44:42,900 --> 00:44:46,000
another chain, and they're doing
this for every single message 

842
00:44:46,000 --> 00:44:48,600
that goes between chains. 
But of course, the downside of 

843
00:44:48,600 --> 00:44:51,600
validity proofs and this is this
is mirrored on to like, CK 

844
00:44:51,600 --> 00:44:52,300
rollers. 
For instance. 

845
00:44:52,300 --> 00:44:55,100
Is that your for every single 
transaction or batch of 

846
00:44:55,100 --> 00:44:56,600
transactions, you're having to 
do this proof. 

847
00:44:56,600 --> 00:44:58,800
And so the cost overhead of it 
is quite High. 

848
00:44:59,100 --> 00:45:03,000
The complexity of is quite High.
The the like cryptographic. 

849
00:45:03,300 --> 00:45:05,800
And like, you know, consensus 
dependencies of this are quite 

850
00:45:05,800 --> 00:45:07,700
High because you have to kind of
figure this out for every single

851
00:45:07,700 --> 00:45:10,600
chain, whereas on, no mat in 
nomadic the other, the other end

852
00:45:10,600 --> 00:45:13,100
of the spectrum, similar 
optimistic Roll-Ups, where you 

853
00:45:13,100 --> 00:45:14,500
actually say, okay. 
Well, we're not actually gonna 

854
00:45:14,500 --> 00:45:16,700
validate anything unless 
something actually goes wrong. 

855
00:45:17,200 --> 00:45:21,900
And so you don't validate like 
you don't submit proofs that any

856
00:45:21,900 --> 00:45:24,300
given State transition or any 
given update is valid. 

857
00:45:24,400 --> 00:45:26,600
Instead. 
You just say, let's just assume 

858
00:45:26,600 --> 00:45:29,400
it's valid and then wait 30 
minutes or wait a certain amount

859
00:45:29,400 --> 00:45:32,200
of time for someone to say. 
Oh they have a problem with us. 

860
00:45:33,300 --> 00:45:36,100
But, but this kind of, this is 
predicated on the assumption 

861
00:45:36,300 --> 00:45:38,600
that there's enough. 
People are kind of watching this

862
00:45:38,600 --> 00:45:39,200
stuff. 
Right? 

863
00:45:39,200 --> 00:45:41,800
So basically, and this is 
something that, I mean, if you 

864
00:45:41,800 --> 00:45:46,000
look at the past six months, or 
so with what has gone wrong with

865
00:45:46,000 --> 00:45:49,000
ridges. 
I mean, I mean the Ronin Bridge.

866
00:45:49,000 --> 00:45:52,400
Heck no one even noticed for 
like five days and I mean, it's 

867
00:45:52,400 --> 00:45:59,300
like I mean, do we have enough 
analytics to be alerted to 

868
00:45:59,300 --> 00:46:03,600
things how many how many? 
How many You call them watches, 

869
00:46:03,600 --> 00:46:07,000
right? 
How many watches do you have on 

870
00:46:07,000 --> 00:46:14,200
these kind of bridges? 
So right now The Watcher set 

871
00:46:14,200 --> 00:46:17,200
Nomad is permissioned. 
The reason for this is just that

872
00:46:17,200 --> 00:46:19,900
it's like a stepping stone, a 
progressive. 

873
00:46:19,900 --> 00:46:22,500
Decentralization process is the 
same reason. 

874
00:46:22,500 --> 00:46:25,000
Why I like optimistic, Roll-Ups,
for instance, don't actually 

875
00:46:25,000 --> 00:46:27,900
Implement fraud proofs. 
So technically they're sort of 

876
00:46:27,900 --> 00:46:30,900
custodial but like obviously 
people recognize that the model 

877
00:46:30,900 --> 00:46:33,700
itself makes sense and Nice. 
That it's a process to get 

878
00:46:33,700 --> 00:46:35,500
there. 
What Nomad is actually working 

879
00:46:35,500 --> 00:46:37,600
on right now is expanding that 
Watcher set. 

880
00:46:38,700 --> 00:46:40,700
So to move away, from just like 
them running, a bunch of 

881
00:46:40,707 --> 00:46:43,900
vultures 22, like allowing other
people to run Watchers. 

882
00:46:43,900 --> 00:46:46,000
It'll still be permission at the
moment, but it will be much 

883
00:46:46,000 --> 00:46:48,200
larger. 
And one of the key goals there 

884
00:46:48,200 --> 00:46:53,700
is to move towards like unlike 
with many other systems in 

885
00:46:53,700 --> 00:46:55,600
Nomads case. 
There are already a bunch of 

886
00:46:55,600 --> 00:46:58,600
actors that are watching the 
chain and looking for fraud. 

887
00:46:58,800 --> 00:47:00,600
A good example of this is 
connects notes. 

888
00:47:00,600 --> 00:47:04,600
So like I guess like 11 kind of 
piece that's missing here. 

889
00:47:04,600 --> 00:47:07,500
Perhaps this context is like, if
Nomad is providing this, like 

890
00:47:07,500 --> 00:47:09,500
messaging layer connects is 
providing liquidity, there 

891
00:47:09,500 --> 00:47:11,400
that's just on top of it. 
And what we do is, we Short 

892
00:47:11,400 --> 00:47:15,200
Circuit, the 30-minute Nomad 
latency in certain cases, where 

893
00:47:15,200 --> 00:47:16,100
it's safe to do. 
So. 

894
00:47:16,800 --> 00:47:20,600
And those cases are cases where 
our nodes are willing to front 

895
00:47:20,600 --> 00:47:23,400
capital for transactions. 
They have the permission to 

896
00:47:23,500 --> 00:47:25,100
execute the transaction on the 
receiving chain. 

897
00:47:25,100 --> 00:47:27,100
So basically like it's a it's a 
nun permission called. 

898
00:47:27,100 --> 00:47:29,800
So like something like a, you 
know, swap swap rather than 

899
00:47:29,800 --> 00:47:33,000
something like a token MIT. 
And then The and most 

900
00:47:33,000 --> 00:47:37,400
importantly they do so only when
they recognize that their fraud 

901
00:47:37,400 --> 00:47:39,200
hasn't actually occurred because
they are the ones that are 

902
00:47:39,200 --> 00:47:41,900
taking on the risk. 
And what's interesting there is 

903
00:47:41,900 --> 00:47:43,800
that they are actually already 
performing the function of a 

904
00:47:43,800 --> 00:47:45,200
larger. 
All we have to do is add a 

905
00:47:45,200 --> 00:47:49,000
little bit more code for them to
like, start a dispute on chain. 

906
00:47:49,700 --> 00:47:54,200
But any all of the like resource
overhead of them watching for 

907
00:47:54,200 --> 00:48:00,000
fraud has already occurred. 
And we have, I think 131 routers

908
00:48:00,000 --> 00:48:02,300
on our test net for the next 
upgrade that includes no, man. 

909
00:48:02,400 --> 00:48:05,900
So that's already 131 Watchers, 
that could go live, pretty much 

910
00:48:05,900 --> 00:48:09,300
immediately which already, you 
know, if you assume I think, if 

911
00:48:09,308 --> 00:48:13,900
you assume like a tent like a 
eighty percent uptime for 

912
00:48:13,900 --> 00:48:16,700
Watchers, I think the odds of 
all of the Watchers being 

913
00:48:16,700 --> 00:48:19,600
offline at the same time, then 
becomes like, in the 10, to 

914
00:48:19,600 --> 00:48:22,700
minus 20 range or something like
that, which is pretty awesome. 

915
00:48:23,800 --> 00:48:27,600
That's low. 
Yeah, as a final Point here, 

916
00:48:27,600 --> 00:48:30,200
this actually, there is a live 
system where this works and has 

917
00:48:30,207 --> 00:48:32,300
been shown to work. 
So like the Ronin Bridge, huh? 

918
00:48:32,500 --> 00:48:36,500
Is a great counter example of 
like why multisig Bridges don't 

919
00:48:36,500 --> 00:48:39,300
work and why you need to make 
sure that you have like, this is

920
00:48:39,300 --> 00:48:41,900
like, it was like the first 
example of like a roost root of,

921
00:48:41,900 --> 00:48:47,300
trust compromise for a bridge 
and shows like the, the risk of 

922
00:48:47,300 --> 00:48:50,700
having, like, you know, this 
like permission-based bridging 

923
00:48:50,700 --> 00:48:53,600
mechanism where you have keys 
that have the ability to 

924
00:48:53,600 --> 00:48:56,800
arbitrarily meant funds on other
chains versus a re vocation 

925
00:48:56,800 --> 00:49:01,300
based bridging mechanism like 
Nomad where you can dispute if 

926
00:49:01,300 --> 00:49:05,100
anyone can dispute. 
If something occurred and but 

927
00:49:05,100 --> 00:49:08,400
you're totally right that like 
it wasn't noticed and I think 

928
00:49:08,400 --> 00:49:11,000
that that was definitely like a 
huge pit failure in. 

929
00:49:11,000 --> 00:49:13,900
Like the that ecosystems part 
that like, there weren't better 

930
00:49:13,900 --> 00:49:16,800
analytics around this but a 
counterexample is like the 

931
00:49:16,800 --> 00:49:18,800
Rainbow Bridge fact that 
happened recently. 

932
00:49:19,700 --> 00:49:23,800
So for context, the Rainbow 
Bridge is a bridge that exists 

933
00:49:23,800 --> 00:49:27,000
between near and ethereum. 
It is a fully trust minimize 

934
00:49:27,000 --> 00:49:30,800
bridge and the way that it works
is that in One Direction. 

935
00:49:30,800 --> 00:49:32,300
It is a fully native Bridge, 
sir. 

936
00:49:32,500 --> 00:49:36,100
Tat Tai DC where I think the 
near ecosystem is running a like

937
00:49:36,100 --> 00:49:39,400
line of theorem. 
And then in the other direction,

938
00:49:39,700 --> 00:49:42,900
it is an optimistic bridge and 
the optimistic Direction was 

939
00:49:42,900 --> 00:49:49,000
attacked and the Watchers of the
Rainbow Bridge axis actually 

940
00:49:49,000 --> 00:49:51,900
successfully detected that an 
attack had had occurred. 

941
00:49:52,300 --> 00:49:55,900
The attack wasn't even like 
fraud from like the the bridge 

942
00:49:55,900 --> 00:49:58,600
updater but was instead in a 
hack of the contracts 

943
00:49:58,600 --> 00:50:02,300
themselves, the Watchers 
successfully detected the hack. 

944
00:50:02,500 --> 00:50:06,000
And pause the bridge. 
So, basically, stopped any sort 

945
00:50:06,000 --> 00:50:11,500
of fall out as a result of, of, 
like the hacker unlike, with 

946
00:50:11,500 --> 00:50:16,900
Ronan or Wormhole or others. 
So, how how do you incentivize 

947
00:50:16,900 --> 00:50:19,200
the watches, right? 
Because basically, if you don't 

948
00:50:19,200 --> 00:50:24,400
incentivize them, basically they
can just hire the chain and 

949
00:50:24,400 --> 00:50:27,800
grief everyone without any cost 
to themselves. 

950
00:50:27,800 --> 00:50:29,600
Right? 
So, in that way, you kind of you

951
00:50:29,607 --> 00:50:33,800
would, you would actually end up
trading security for liveness? 

952
00:50:35,800 --> 00:50:39,500
That is actually the main 
research question and optimizing

953
00:50:39,500 --> 00:50:42,200
that process is the main 
research question that remains 

954
00:50:42,600 --> 00:50:44,500
to be able to make Watchers 
permissionless. 

955
00:50:45,500 --> 00:50:49,900
The general idea is that you can
use a combination of things like

956
00:50:49,900 --> 00:50:54,600
token incentives, and then also 
like bonds and slashing of those

957
00:50:54,600 --> 00:50:59,000
bonds to be able to ensure that,
you know, updaters are penalized

958
00:50:59,000 --> 00:51:03,300
for fraud and then Watchers are 
penalized for false reports of 

959
00:51:03,300 --> 00:51:06,900
Fraud. 
And The the like there's no real

960
00:51:06,900 --> 00:51:09,800
like material like Financial 
upside, for a watcher to do this

961
00:51:09,800 --> 00:51:13,200
other than like the griefing 
Vector of dowsing. 

962
00:51:13,700 --> 00:51:17,500
And so, as long as the, the 
downside risk for a watcher of, 

963
00:51:17,900 --> 00:51:19,800
hey, I'm going to lose x y, z 
amount of funds. 

964
00:51:19,800 --> 00:51:24,300
If I've like fraudulently, you 
know, stopped this bridge is as 

965
00:51:24,300 --> 00:51:26,300
long as that's the case. 
You can be reasonably certain 

966
00:51:26,300 --> 00:51:27,400
that. 
It doesn't really make a lot of 

967
00:51:27,400 --> 00:51:29,200
sense for what for like Watchers
to do that. 

968
00:51:29,500 --> 00:51:32,200
Now, there's there's there's 
definitely a lot of like 

969
00:51:32,200 --> 00:51:34,600
research that is currently in 
progress around this to figure 

970
00:51:34,600 --> 00:51:36,500
out. 
Out, what are the bounds around 

971
00:51:36,500 --> 00:51:37,900
that? 
Like, how can we be sure that, 

972
00:51:37,900 --> 00:51:41,200
like the penalties for this are 
high enough for Watchers to be 

973
00:51:42,700 --> 00:51:46,600
to be disincentivized from like,
you know, tossing and then. 

974
00:51:46,600 --> 00:51:49,000
Similarly. 
How do you ensure that the the 

975
00:51:49,000 --> 00:51:51,500
rewards are high enough for 
Watchers to be incentivized to 

976
00:51:51,500 --> 00:51:53,300
actually like attempt 
transactions? 

977
00:51:53,300 --> 00:51:56,100
And how do you make sure? 
For instance, that like, if 

978
00:51:56,100 --> 00:52:00,000
there are rewards, it is not 
possible to front run those for 

979
00:52:00,000 --> 00:52:02,800
like, you know, and maybe Bots 
to front run of those rewards in

980
00:52:02,800 --> 00:52:05,000
the temple, which is which 
happen. 

981
00:52:05,200 --> 00:52:06,700
In the near Rainbow Bridge case 
subscribed. 

982
00:52:06,700 --> 00:52:08,900
Interesting. 
So these are the kinds of 

983
00:52:08,900 --> 00:52:11,700
questions that I think like 
Nomads researchers are dealing 

984
00:52:11,700 --> 00:52:16,400
with at the moment that are the 
main blockers to being able to 

985
00:52:16,400 --> 00:52:19,800
completely open the system up. 
Quite yeah, super exciting. 

986
00:52:20,300 --> 00:52:21,200
For what it's worth. 
By the way. 

987
00:52:21,200 --> 00:52:25,200
These are also the same same 
research questions that exist in

988
00:52:25,200 --> 00:52:27,300
optimistic Roll-Ups around 
instead of Isaac Watchers. 

989
00:52:29,000 --> 00:52:32,900
So basically seeing that 
connects basically offers 

990
00:52:33,500 --> 00:52:37,500
liquidity or liquidity 
underwriting on top of on top of

991
00:52:37,500 --> 00:52:41,000
the bridge. 
How do you deal with? 

992
00:52:41,200 --> 00:52:44,300
How do you think about re Orcs 
And probabilistic finality, 

993
00:52:44,300 --> 00:52:46,200
right? 
Because basically if if 

994
00:52:46,207 --> 00:52:49,300
something happens on the chain 
that you send something from 

995
00:52:49,300 --> 00:52:53,600
NPC, three orbs then and you 
have already paid out the money 

996
00:52:53,600 --> 00:52:57,300
on the other check and chain. 
I mean it said kind of priced in

997
00:52:57,300 --> 00:53:02,200
or do you have It, can you 
somehow mitigate that Danger? 

998
00:53:04,400 --> 00:53:09,600
This is a part of the risk of 
running routers and text and 

999
00:53:09,600 --> 00:53:12,000
this is the this is the risk 
that we try to mitigate is like 

1000
00:53:12,500 --> 00:53:15,300
the the risk as a router. 
Basically, what you're doing is 

1001
00:53:15,300 --> 00:53:18,700
you're saying I see that there 
is a slope slow, 30-minute 

1002
00:53:18,700 --> 00:53:20,100
transaction that's coming over 
to Med. 

1003
00:53:20,500 --> 00:53:23,900
I see that it is possible for me
to complete this transaction 

1004
00:53:23,900 --> 00:53:26,600
faster and I see that I have 
enough liquidity to do so and I 

1005
00:53:26,607 --> 00:53:28,600
can earn a small amount of feast
by doing that. 

1006
00:53:29,300 --> 00:53:32,100
And so we sort of like, mitigate
the, the latency trade-off of 

1007
00:53:32,100 --> 00:53:34,300
nomad. 
We also ensure that the User 

1008
00:53:34,300 --> 00:53:36,100
gets the right asset that they 
need. 

1009
00:53:36,400 --> 00:53:41,300
And we make sure that and like 
the only kind of the the, I 

1010
00:53:41,300 --> 00:53:44,000
guess the trade-off for not 
necessarily the trade-off but at

1011
00:53:44,000 --> 00:53:47,300
least like the the decision 
Matrix around doing that is then

1012
00:53:47,300 --> 00:53:50,000
based on what is the risk to the
router that is actually making 

1013
00:53:50,000 --> 00:53:53,400
this happen. 
And that, that risk profile is 

1014
00:53:53,400 --> 00:53:56,200
based on, You Know, How likely 
is it? 

1015
00:53:56,200 --> 00:53:57,500
That fraud has occurred at 
Nomad? 

1016
00:53:59,100 --> 00:54:01,900
What is the risk of some sort of
like chain event like a reorder,

1017
00:54:01,900 --> 00:54:06,400
51% attack and And what is the 
risk of like some sort of 

1018
00:54:06,400 --> 00:54:08,800
failure, like some sort of 
failure mode on the receiving 

1019
00:54:08,800 --> 00:54:12,500
chain that results in like me as
a router, not being paid out in 

1020
00:54:12,500 --> 00:54:15,800
the rear case at the moment. 
What we just do is, wait, you 

1021
00:54:15,800 --> 00:54:18,100
just wait for enough blocks. 
We've done a lot of like 

1022
00:54:18,100 --> 00:54:20,900
statistical analysis over the 
course of the last year and a 

1023
00:54:20,908 --> 00:54:26,200
half to just like just because 
we've been live for that long to

1024
00:54:26,200 --> 00:54:28,300
be able to understand how many 
blocks we need to wait on each 

1025
00:54:28,300 --> 00:54:32,500
chain, and and generally, what 
we found is like the reorg risk 

1026
00:54:32,500 --> 00:54:38,700
is really only biggest. 
And like Fast chains that are 

1027
00:54:38,700 --> 00:54:43,700
have like very very low fees 
like BSC and polygons where you 

1028
00:54:43,700 --> 00:54:47,900
can see like deeper yards and on
most other chains that isn't as 

1029
00:54:47,900 --> 00:54:50,100
much of a concern. 
So usually waiting about two 

1030
00:54:50,100 --> 00:54:52,100
minutes everywhere. 
It appears to work quite well. 

1031
00:54:52,500 --> 00:54:54,500
Well, we'd like to do is move 
towards a model where we 

1032
00:54:54,500 --> 00:54:56,700
actually don't need to wait for 
a reorg risk, but that's quite 

1033
00:54:56,700 --> 00:54:58,900
difficult. 
So, some things that have been 

1034
00:54:58,900 --> 00:55:00,800
talked about in our community. 
For instance, are the 

1035
00:55:00,800 --> 00:55:03,700
possibility of building some 
sort of reorganize words where 

1036
00:55:04,000 --> 00:55:09,000
You actually just like have 
users underwrite the risk of the

1037
00:55:09,000 --> 00:55:12,300
reorg risk of a router and like 
because you can detect like re 

1038
00:55:12,300 --> 00:55:14,400
ords in on chain within a 
contract. 

1039
00:55:14,400 --> 00:55:17,800
You could actually 
deterministically, payout that 

1040
00:55:17,800 --> 00:55:22,100
insurance bound to a router, if,
for every or occurs, but the 

1041
00:55:22,500 --> 00:55:24,600
again like the, this is 
something that's been like 

1042
00:55:24,600 --> 00:55:25,900
talked about in theoretical 
terms. 

1043
00:55:25,900 --> 00:55:28,000
But like the economics of it are
something that we'd need to 

1044
00:55:28,000 --> 00:55:31,000
figure out like, basically, what
is the likelihood of reorge? 

1045
00:55:31,300 --> 00:55:34,000
What is that scale of risk 
versus? 

1046
00:55:34,100 --> 00:55:36,600
Reward look like and what kind 
of fees would you need to charge

1047
00:55:36,600 --> 00:55:40,300
as an insurance provider in 
order to mitigate the massive 

1048
00:55:40,300 --> 00:55:42,500
additional risk that you might 
have on some other chains? 

1049
00:55:43,600 --> 00:55:47,800
Yeah, I mean as soon as as soon 
as a theorem and possibly a lot 

1050
00:55:47,800 --> 00:55:52,500
of other evm based chains move 
to proof of stake, I mean, the 

1051
00:55:52,500 --> 00:55:58,000
real risk, I mean, it doesn't 
fully go away but it reduces 

1052
00:55:58,000 --> 00:56:00,300
greatly right. 
So reduces. 

1053
00:56:00,300 --> 00:56:03,600
Yeah, and we've been working 
with like we've been working 

1054
00:56:03,600 --> 00:56:06,600
closely with the polygon team 
for instance on on on this 

1055
00:56:06,600 --> 00:56:08,500
problem to try to talk them 
about like what are ways to 

1056
00:56:08,500 --> 00:56:10,800
think about this. 
I know that this is like a huge 

1057
00:56:10,800 --> 00:56:13,100
party for them as well. 
But like they are trying to 

1058
00:56:13,100 --> 00:56:14,800
work. 
Improving their own consensus 

1059
00:56:14,800 --> 00:56:17,400
mechanisms and the way that like
nodes operate in their Network 

1060
00:56:17,700 --> 00:56:21,600
to be able to reduce the rate 
and depth over yards as much as 

1061
00:56:21,600 --> 00:56:24,400
possible. 
But yeah, it's definitely it is 

1062
00:56:24,400 --> 00:56:27,200
definitely a problem right now 
with problematic finality and 

1063
00:56:27,200 --> 00:56:30,800
the solution of the problem is 
just for us to wait longer for 

1064
00:56:30,800 --> 00:56:32,500
routers to wait longer long 
enough that they are 

1065
00:56:32,500 --> 00:56:35,000
comfortable. 
Quick. 

1066
00:56:35,100 --> 00:56:37,700
So how do you guys think about 
Capital efficiency? 

1067
00:56:37,700 --> 00:56:41,100
So basically, if you if you 
move, if you're kind of 

1068
00:56:41,100 --> 00:56:44,800
liquidity, underwriter this kind
of entails having Capital at 

1069
00:56:44,800 --> 00:56:49,000
hand, to kind of pay people out.
So, how do you think about not 

1070
00:56:49,000 --> 00:56:53,100
having too much on anyone 
stockpile? 

1071
00:56:54,500 --> 00:56:57,700
Camera person sees a really 
interesting question and 

1072
00:56:57,700 --> 00:57:02,100
problem. 
Like the ideal sort of scenario,

1073
00:57:02,200 --> 00:57:04,500
which is what we had originally 
tried to optimize for was like, 

1074
00:57:04,900 --> 00:57:09,200
you have a certain amount of 
liquidity available in each 

1075
00:57:09,200 --> 00:57:11,300
chain, and then you're just 
like, utilizing that pool of 

1076
00:57:11,300 --> 00:57:13,400
liquidity to do transactions. 
And there's no additional 

1077
00:57:13,400 --> 00:57:15,500
liquidity that's required in. 
There's no lockups of liquidity.

1078
00:57:15,500 --> 00:57:21,300
That's required and so our 
existing system, you know, the 

1079
00:57:21,300 --> 00:57:23,100
kind of V one of our 
interoperability Network. 

1080
00:57:23,800 --> 00:57:26,700
Does this thing where like you, 
you know, you send transactions 

1081
00:57:26,700 --> 00:57:28,500
to a router and through an 
atomic swap. 

1082
00:57:28,500 --> 00:57:31,000
It, the router receives funds on
one chain, and then they give 

1083
00:57:31,000 --> 00:57:33,300
you funds on another chain. 
And in theory, this is the most 

1084
00:57:33,300 --> 00:57:36,800
like Capital efficient option, 
but what's interesting is that, 

1085
00:57:37,200 --> 00:57:38,800
there's a capital efficiency and
then there's Capital 

1086
00:57:38,800 --> 00:57:41,300
utilization. 
What's interesting is that like 

1087
00:57:41,300 --> 00:57:43,400
the utilization is actually not 
that great even though, even if 

1088
00:57:43,400 --> 00:57:45,400
the efficiency is great. 
And the reason for this is that 

1089
00:57:45,800 --> 00:57:49,400
while the liquidity, you know, 
say you're transacting like 

1090
00:57:49,400 --> 00:57:51,300
currently there's a lot of 
people that are, you know, 

1091
00:57:51,700 --> 00:57:53,400
transacting getting out of FTM 
and go. 

1092
00:57:53,600 --> 00:57:56,900
The chance to say you're going 
from FTM to polygons while the 

1093
00:57:57,300 --> 00:58:02,500
the liquidity that a user sends,
an FTM is immediately usable by 

1094
00:58:02,500 --> 00:58:04,700
the router to send a transaction
the opposite direction. 

1095
00:58:05,200 --> 00:58:09,600
What we found is that in many, 
in most cases, the the movement 

1096
00:58:09,600 --> 00:58:13,700
of funds between chains and the,
the patterns by which people 

1097
00:58:13,800 --> 00:58:18,700
tend to rotate between chains 
are unidirectional week to week.

1098
00:58:18,800 --> 00:58:20,600
So, you know, the chain may 
change. 

1099
00:58:20,600 --> 00:58:23,200
But like everybody will flood to
it given chain, or float away 

1100
00:58:23,200 --> 00:58:25,800
from it. 
Even China in a given week and 

1101
00:58:26,200 --> 00:58:28,600
and the difficulty with this is 
that now you end up at least 

1102
00:58:28,600 --> 00:58:30,600
with what exists, currently you 
end up with, like liquidy 

1103
00:58:30,600 --> 00:58:32,700
actually, just piling up in a, 
given on a given in a given 

1104
00:58:32,700 --> 00:58:34,800
place. 
So like, for instance, you know,

1105
00:58:34,800 --> 00:58:36,900
tons of the QWERTY piles up on 
FTM because everybody's trying 

1106
00:58:36,900 --> 00:58:39,800
to exit that chain and in order 
to fix that, in order to make 

1107
00:58:39,800 --> 00:58:42,100
sure that that Capital, you 
know, wild that capital is 

1108
00:58:43,100 --> 00:58:46,700
usable by someone who's going 
into FTM because the demand for 

1109
00:58:46,700 --> 00:58:49,600
going into fdm is low. 
We want to we net then need to 

1110
00:58:49,600 --> 00:58:51,900
have the secondary problem of. 
How do we get liquidity off of 

1111
00:58:51,900 --> 00:58:54,700
FTM and to somewhere else? 
It's more likely to be used. 

1112
00:58:55,200 --> 00:58:57,600
It's a utilization of that 
capital on zippy quite low. 

1113
00:58:58,700 --> 00:59:01,100
What we ultimately came to the 
conclusion of was like, it's 

1114
00:59:01,100 --> 00:59:04,000
actually better for instead of 
you know, it's better for us to 

1115
00:59:04,000 --> 00:59:06,700
actually take a hit with capital
efficiency if we can increase 

1116
00:59:06,700 --> 00:59:10,300
utilization and and what we 
decided was to move towards this

1117
00:59:10,300 --> 00:59:14,900
model where routers and our 
Network send and receive capital

1118
00:59:14,900 --> 00:59:17,800
on the same network. 
So the sender receive Capital 

1119
00:59:17,800 --> 00:59:19,600
the same chain so that they 
don't have to deal with this 

1120
00:59:19,600 --> 00:59:22,600
process of rebalancing. 
And, and the process of running 

1121
00:59:22,600 --> 00:59:25,200
a router becomes like, As 
possible as fast as possible, 

1122
00:59:25,200 --> 00:59:28,000
they could, they can just, like,
sort of turn it on, put it, put 

1123
00:59:28,000 --> 00:59:30,300
liquidity in and then just like,
let it happen. 

1124
00:59:31,100 --> 00:59:35,800
And this results in the best 
utilization, because routers 

1125
00:59:35,800 --> 00:59:38,700
don't have to think about, you 
don't have liquidity piling up 

1126
00:59:38,700 --> 00:59:40,000
on chains that are not being 
used. 

1127
00:59:40,500 --> 00:59:43,900
And the trade-off here is that 
now there is a couple efficiency

1128
00:59:43,900 --> 00:59:47,300
problem so or not really a 
problem, but you have a slightly

1129
00:59:47,300 --> 00:59:49,300
reduced Capital efficiency. 
So now what happens in our 

1130
00:59:49,300 --> 00:59:52,600
network is like you have this 
the base layer of this whole 

1131
00:59:52,600 --> 00:59:55,400
process is Is the transaction 
that happens across chains with 

1132
00:59:55,400 --> 00:59:59,600
Nomad, where you burn a nomad 
representative acid on one chain

1133
00:59:59,600 --> 01:00:01,400
and then mint. 
Another node representing office

1134
01:00:01,400 --> 01:00:05,500
acid another chain, but in order
to make that process happen 

1135
01:00:05,500 --> 01:00:09,700
faster, the router needs to, you
know, basically like avoid the 

1136
01:00:09,700 --> 01:00:11,400
30 minutes of waiting for the 
user. 

1137
01:00:11,400 --> 01:00:13,400
The router now needs to take on 
that 30-minute lockup. 

1138
01:00:13,400 --> 01:00:16,200
So, the router now has their 
Capital efficiency reduced 

1139
01:00:16,200 --> 01:00:19,600
because they are there. 
Their capital is, is locked up 

1140
01:00:19,600 --> 01:00:21,100
for 30 minutes, every time they 
use it. 

1141
01:00:21,400 --> 01:00:23,400
And then second then, in 
addition to that. 

1142
01:00:23,500 --> 01:00:27,400
You now also need user-provided 
kind of passively provided 

1143
01:00:27,400 --> 01:00:32,100
liquidity on each chain in the 
stable swap that that where if 

1144
01:00:32,100 --> 01:00:35,800
needed you are swapping from The
Nomad representative asset to 

1145
01:00:35,800 --> 01:00:40,400
the canonical asset on that 
chain that said, I think because

1146
01:00:40,400 --> 01:00:43,800
of the new mechanism we actually
will end up with much better, 

1147
01:00:44,600 --> 01:00:48,500
Capital availability and 
utilization and also probably 

1148
01:00:48,500 --> 01:00:52,400
much better pricing than the 
reason for this is just that the

1149
01:00:52,400 --> 01:00:55,800
price curve. 
Like, basically the incentive to

1150
01:00:55,800 --> 01:00:58,500
rebalance the system. 
In this case, what rebalancing 

1151
01:00:58,500 --> 01:01:01,400
means is basically swapping 
assets back into Nomad a 

1152
01:01:01,408 --> 01:01:03,900
flavored acids and sending them 
in the opposite direction to 

1153
01:01:03,900 --> 01:01:06,800
another chain, to basically 
generate more Nomad. 

1154
01:01:06,800 --> 01:01:11,400
The critic, their, the incentive
to do that is now concentrated 

1155
01:01:11,400 --> 01:01:14,600
in the stable swaps on each 
chain. 

1156
01:01:14,700 --> 01:01:17,200
So the pricing is concentrated, 
which means that you have the 

1157
01:01:17,200 --> 01:01:20,700
best possible pricing, that 
least amount of slippage versus 

1158
01:01:20,700 --> 01:01:23,200
having, you know, each router 
have their own pricing curve at 

1159
01:01:23,200 --> 01:01:25,800
things. 
Oh, that and then, in addition 

1160
01:01:25,800 --> 01:01:30,500
to that, while there is a 
lock-up of funds not lock up is 

1161
01:01:30,500 --> 01:01:35,600
actually relatively small 
compared to the amount of the 

1162
01:01:35,600 --> 01:01:38,000
possible utilization of those 
funds and the frequency with 

1163
01:01:38,000 --> 01:01:39,300
which you could rebound sit in 
the past. 

1164
01:01:39,300 --> 01:01:42,500
So, for example, say, you know, 
pessimistically say like The 

1165
01:01:42,500 --> 01:01:44,900
Nomad lock up, takes a full hour
in case we decide to do 

1166
01:01:44,900 --> 01:01:46,200
batching. 
I think so that we're not at the

1167
01:01:46,200 --> 01:01:49,400
moment, but say we do that in 
the future, even if you do, even

1168
01:01:49,400 --> 01:01:55,400
if it takes a full hour, if the 
network has Say the network has 

1169
01:01:55,700 --> 01:01:57,200
a hundred million dollars of the
corridor. 

1170
01:01:57,200 --> 01:01:59,600
Currently. 
We have about, you know, forty 

1171
01:01:59,600 --> 01:02:02,200
million dollars of the QWERTY. 
So say the network has 40 

1172
01:02:02,200 --> 01:02:05,800
million dollars liquidity. 
That is that is locked up for a 

1173
01:02:05,800 --> 01:02:09,500
maximum of one hour. 
Every time it is used utilize 

1174
01:02:09,800 --> 01:02:12,100
that means with 40 million 
dollars of the QWERTY you could 

1175
01:02:12,100 --> 01:02:14,100
do over a billion dollars of 
daily volume. 

1176
01:02:15,300 --> 01:02:19,100
So that's far more Capital 
should than many other things in

1177
01:02:19,100 --> 01:02:21,500
the space anyway, so at that 
point where like, okay this this

1178
01:02:21,500 --> 01:02:25,400
is this makes sense from from a 
efficiency and utilization 

1179
01:02:25,400 --> 01:02:29,500
perspective. 
What's the fee you take in terms

1180
01:02:29,500 --> 01:02:33,800
of basis points? 
Yeah, there's a there's several 

1181
01:02:33,800 --> 01:02:35,100
different kinds of pieces that 
work. 

1182
01:02:36,500 --> 01:02:40,300
There is a fee that routers take
for the lock-up of the clarity 

1183
01:02:40,500 --> 01:02:44,600
and that is five basis points 
over time that may reduce or 

1184
01:02:44,600 --> 01:02:47,100
increase depending on like the 
network Dynamics and things of 

1185
01:02:47,100 --> 01:02:48,100
that. 
We haven't quite figured out 

1186
01:02:48,100 --> 01:02:49,200
yet. 
But we have found that five 

1187
01:02:49,200 --> 01:02:52,800
basis points is like usually 
about 10x cheaper than most 

1188
01:02:52,800 --> 01:02:56,900
other options out there and and 
in even if it isn't it is 

1189
01:02:56,900 --> 01:02:58,500
definitely significantly 
cheaper. 

1190
01:02:58,900 --> 01:03:01,000
It is definitely the cheapest 
option by far out there at the 

1191
01:03:01,000 --> 01:03:03,400
moment. 
And then, in addition to that, 

1192
01:03:03,400 --> 01:03:04,600
there are two other kinds of 
fees. 

1193
01:03:04,600 --> 01:03:10,100
So there is there are the lp 
fees for the stable swaps and we

1194
01:03:10,100 --> 01:03:12,300
don't quite know exactly what 
those will be yet, but that will

1195
01:03:12,300 --> 01:03:16,400
be like a small fee that is paid
that out to the the passive LPS 

1196
01:03:16,400 --> 01:03:18,600
of the stable Swap. 
And then, in addition to that, 

1197
01:03:18,600 --> 01:03:20,600
of course, like the slippage in 
that stable swap. 

1198
01:03:21,200 --> 01:03:24,600
Generally, we expect these to be
fairly tight because these are 

1199
01:03:24,600 --> 01:03:26,600
all using, you know, stable swap
AMS. 

1200
01:03:26,600 --> 01:03:28,000
There are highly optimized for 
this. 

1201
01:03:29,100 --> 01:03:32,400
And and generally speaking, this
is Passive liquidity. 

1202
01:03:32,400 --> 01:03:35,300
So we expect that users. 
It's like much easier easier for

1203
01:03:35,300 --> 01:03:37,500
us to bootstrap the per day. 
When users are able to passively

1204
01:03:37,500 --> 01:03:40,600
LP. 
The last kind of fee is gas 

1205
01:03:40,600 --> 01:03:44,500
phase. 
So users need to pay the gas of 

1206
01:03:44,500 --> 01:03:47,600
the transactions that they do on
both the sending and receiving 

1207
01:03:47,600 --> 01:03:50,400
trades. 
They pay this all of this. 

1208
01:03:50,500 --> 01:03:54,800
In the ascending chain asset, 
sending chain, like native acid.

1209
01:03:55,100 --> 01:03:58,800
And the, the idea behind this is
that like we realized in the 

1210
01:03:58,800 --> 01:04:02,900
past we have users, pay gas fees
from You know, the transacted 

1211
01:04:02,900 --> 01:04:03,800
asset. 
So like you SC. 

1212
01:04:03,800 --> 01:04:06,500
See, for instance, if it's going
across chains, when we realized 

1213
01:04:06,500 --> 01:04:11,500
is that like if we end up having
long tail assets, it may not be 

1214
01:04:11,500 --> 01:04:13,900
the case that, you know, re 
layers and other other like 

1215
01:04:13,900 --> 01:04:18,200
service providers of are willing
to accept fees in XYZ long. 

1216
01:04:18,200 --> 01:04:20,500
Tail asset trick coin that 
doesn't even have like a market 

1217
01:04:20,500 --> 01:04:23,500
price. 
And so, what we decided was that

1218
01:04:23,500 --> 01:04:27,200
the the most acceptable form of 
asset that we can be sure that 

1219
01:04:27,200 --> 01:04:29,600
users will have and that re 
layers and other service 

1220
01:04:29,600 --> 01:04:31,500
providers will be willing to 
accept. 

1221
01:04:31,800 --> 01:04:34,800
Will always be the sending chain
native asset and the user 

1222
01:04:34,800 --> 01:04:36,700
experience of this is kind of 
nice as well, because the 

1223
01:04:36,700 --> 01:04:39,300
developer experience is kind of 
nice as well, because all users 

1224
01:04:39,300 --> 01:04:41,800
are doing is that they're just 
paying some additional gas fees 

1225
01:04:41,800 --> 01:04:44,000
on top of the gas phase, if they
would already paying to do a 

1226
01:04:44,008 --> 01:04:47,000
transactional that chain and 
similarity, similarly, as a 

1227
01:04:47,000 --> 01:04:51,400
developer, you are just, you 
know, making sure that the user 

1228
01:04:51,400 --> 01:04:54,200
pays this additional fee and 
then monitoring and bumping that

1229
01:04:54,200 --> 01:04:56,800
fee. 
If needed, you know, if you need

1230
01:04:56,800 --> 01:04:58,700
the transaction to go through 
faster or something that on the 

1231
01:04:58,700 --> 01:05:02,900
receiving chain. 
But I mean that sounds like 

1232
01:05:02,900 --> 01:05:04,300
really good business model 
though. 

1233
01:05:04,300 --> 01:05:07,000
So, I mean, basically if you I 
mean I'm talking about the five 

1234
01:05:07,000 --> 01:05:11,000
basis points for the liquidity 
provision for the half hour. 

1235
01:05:11,000 --> 01:05:14,700
Right? 
So basically if you kind of if 

1236
01:05:14,700 --> 01:05:21,800
you had like perfect Capital 
utilization and you that meant 

1237
01:05:21,800 --> 01:05:29,300
you could kind of have a billion
dollars of volume day and 

1238
01:05:29,300 --> 01:05:33,700
basically you You got your your 
risk management right to that 

1239
01:05:33,700 --> 01:05:37,700
basically wouldn't be to paying 
a lot for that that that's like 

1240
01:05:37,700 --> 01:05:40,500
five basis points on the billion
dollars is like a half a million

1241
01:05:40,500 --> 01:05:47,200
a day, right? 
yeah, there's a It is a really 

1242
01:05:47,200 --> 01:05:51,300
lucrative model and it is 
extremely low risk. 

1243
01:05:51,300 --> 01:05:54,100
So this is a way for people to 
run infrastructure and get an 

1244
01:05:54,100 --> 01:05:56,700
extremely low risk, like 
potentially. 

1245
01:05:56,700 --> 01:05:58,000
I mean, of course, it's 
demand-driven. 

1246
01:05:58,000 --> 01:06:00,000
And I think like the demand of 
the network ultimately is going 

1247
01:06:00,000 --> 01:06:02,000
to be what the results in 
returns, for the router 

1248
01:06:02,000 --> 01:06:03,900
operators. 
And basically, the ratio of the 

1249
01:06:03,900 --> 01:06:06,200
demand in the network to like 
the amount of liquidity provided

1250
01:06:07,000 --> 01:06:09,800
by router operators, but at the 
same time, like in a divot 

1251
01:06:09,800 --> 01:06:12,900
demand-driven scenario, like, 
you can easily get like 50 plus 

1252
01:06:12,900 --> 01:06:15,000
percent on any asset that you're
providing liquidity. 

1253
01:06:15,700 --> 01:06:19,500
A pra PR, if you are. 
So, that's crazy. 

1254
01:06:20,400 --> 01:06:22,800
Actually would be a PR. 
So, it's actually even more apy.

1255
01:06:24,500 --> 01:06:29,500
Wow. 
So let's talk about, we're kind 

1256
01:06:29,500 --> 01:06:32,000
of over time already, but 
there's one thing I really want 

1257
01:06:32,000 --> 01:06:35,800
to cover. 
So let's talk about the user 

1258
01:06:35,800 --> 01:06:38,500
experience. 
So I mean, item ately, what you 

1259
01:06:38,500 --> 01:06:42,800
want, is the user shouldn't have
to know which chain there on. 

1260
01:06:43,100 --> 01:06:47,100
So, I mean, so basically, if I 
Want, I should go to adapt and 

1261
01:06:47,100 --> 01:06:54,600
it should just work and I mean, 
especially with the defy 

1262
01:06:54,600 --> 01:06:58,200
Primitives. 
We've kind of seen in the past. 

1263
01:06:58,600 --> 01:07:05,000
How is composed ability of those
defy Primitives other Primitives

1264
01:07:05,000 --> 01:07:07,300
to be honest? 
And bridges. 

1265
01:07:07,500 --> 01:07:10,400
How's that gonna come together? 
Because it seems like too 

1266
01:07:10,400 --> 01:07:13,900
difficult problems. 
Is this a tractable problem? 

1267
01:07:15,400 --> 01:07:18,800
Yeah, that's a good question. 
I think what we're experiencing 

1268
01:07:18,800 --> 01:07:22,300
right now is like the like 
basically what we need to go 

1269
01:07:22,300 --> 01:07:26,800
through this transition from 
Application like, decentralized 

1270
01:07:26,800 --> 01:07:29,800
application development going 
from being like a something that

1271
01:07:29,800 --> 01:07:32,400
you do in like the synchronous 
model where everything runs on a

1272
01:07:32,408 --> 01:07:35,800
single chain and I'm like, you 
can be sure that like you have 

1273
01:07:35,800 --> 01:07:38,800
results within the same block 
for anything that you build 

1274
01:07:39,000 --> 01:07:42,000
versus moving to an asynchronous
model, that is more similar to 

1275
01:07:42,000 --> 01:07:43,900
how web applications are built 
more broadly. 

1276
01:07:45,200 --> 01:07:48,100
And and I think the difficult 
part will be figuring out how to

1277
01:07:48,100 --> 01:07:51,800
make that transition happen with
whilst making sure that the 

1278
01:07:51,800 --> 01:07:54,200
developer experience and user 
experience remains as similar to

1279
01:07:54,200 --> 01:07:58,400
what exists is. 
I definitely think that like, I 

1280
01:07:58,400 --> 01:08:02,700
definitely like our thesis is 
always been that most users and 

1281
01:08:02,700 --> 01:08:05,400
users, especially are not going 
to really care at all about what

1282
01:08:05,400 --> 01:08:06,800
chain, they're on their, they 
don't want to. 

1283
01:08:06,800 --> 01:08:08,800
And like really, they're just 
gonna want to use an 

1284
01:08:08,800 --> 01:08:10,800
application. 
And so if you, if you're 

1285
01:08:10,800 --> 01:08:14,000
operating under those 
assumptions, then it should just

1286
01:08:14,000 --> 01:08:16,500
be possible it. 
You should move towards a world 

1287
01:08:16,500 --> 01:08:18,399
where if you're building an 
application that application to 

1288
01:08:18,399 --> 01:08:20,800
be able to, like, accept 
transactions from any chain, and

1289
01:08:20,800 --> 01:08:22,800
should be able to potentially 
even have like, liquidity 

1290
01:08:22,800 --> 01:08:24,700
Bullseye, multiple chains that 
are connected to each other. 

1291
01:08:25,500 --> 01:08:28,700
I think that's possible but it 
will involve like a transition 

1292
01:08:29,100 --> 01:08:31,600
that we are trying to make 
happen right now, which is that 

1293
01:08:32,500 --> 01:08:34,700
developers are going to have to 
move to a mental model where 

1294
01:08:34,700 --> 01:08:37,399
they are not necessarily 
receiving the results from a 

1295
01:08:37,407 --> 01:08:38,899
given transaction immediately 
there. 

1296
01:08:38,899 --> 01:08:42,100
Instead having to do what you 
currently do when like building 

1297
01:08:42,100 --> 01:08:44,800
an application with JavaScript. 
For instance, where you make an 

1298
01:08:44,800 --> 01:08:47,000
asynchronous transaction or 
asynchronous call to another 

1299
01:08:47,000 --> 01:08:49,200
function. 
That's just another process of 

1300
01:08:49,200 --> 01:08:50,600
living somewhere else on the 
internet. 

1301
01:08:50,899 --> 01:08:53,000
And you don't know when you're 
going to get response. 

1302
01:08:53,000 --> 01:08:54,600
You don't know if you're going 
to get a response to. 

1303
01:08:54,600 --> 01:08:57,100
So now, To have handlers for 
this, you need to have an error 

1304
01:08:57,100 --> 01:08:58,399
Handler. 
That handles. 

1305
01:08:58,399 --> 01:09:00,300
What happens. 
If you don't get a response, you

1306
01:09:00,300 --> 01:09:03,000
get an error. 
And then you also need to have a

1307
01:09:03,000 --> 01:09:06,899
callback that, or at least a 
callback Handler, that that 

1308
01:09:06,899 --> 01:09:11,300
basically is executed when the 
return data comes back from 

1309
01:09:11,300 --> 01:09:14,200
another chain, which maybe at 
some point may, you know, given 

1310
01:09:14,200 --> 01:09:17,100
Nomad latency be like 30 minutes
or so, in the future. 

1311
01:09:17,700 --> 01:09:21,500
But yeah, it's a good question. 
I think like, it's going to be 

1312
01:09:21,508 --> 01:09:24,300
quite interesting to see how 
this stuff plays out generally 

1313
01:09:24,399 --> 01:09:30,800
from our - what we've seen is 
that, like most, if not, all 

1314
01:09:30,800 --> 01:09:33,399
user-facing, interactions can be
short-circuited by connects. 

1315
01:09:34,000 --> 01:09:36,000
And so those can happen in under
two minutes. 

1316
01:09:36,500 --> 01:09:38,500
And so what that means is, like,
if you are a user that's like, 

1317
01:09:38,500 --> 01:09:40,600
trying to use you to swap 
another chain, or you're trying 

1318
01:09:40,600 --> 01:09:43,300
to just like, get the best say, 
for example, you are using Paris

1319
01:09:43,300 --> 01:09:45,200
off, and you want to get the 
best rate across all chains. 

1320
01:09:46,600 --> 01:09:49,800
Paris walk can actually, it's 
like create transactions that go

1321
01:09:49,800 --> 01:09:52,300
through connects that aggregate 
all of their liquidity on 

1322
01:09:52,300 --> 01:09:54,700
multiple chains all together and
that can happen in two minutes. 

1323
01:09:55,000 --> 01:09:57,800
Because the the, you know, the 
the decks calls on each chain 

1324
01:09:57,800 --> 01:10:00,300
are on permission and given that
that's the case. 

1325
01:10:00,300 --> 01:10:03,900
Like we expect generally that 
that's going to be an acceptable

1326
01:10:03,900 --> 01:10:06,900
user experience food. 
For for most users who are used 

1327
01:10:06,900 --> 01:10:09,400
to like using web applications 
and dealing with that kind of 

1328
01:10:09,400 --> 01:10:11,800
agency. 
And and we think there are ways 

1329
01:10:11,800 --> 01:10:13,600
to kind of like, how is that 
latency? 

1330
01:10:13,700 --> 01:10:16,400
Like at least a latency increase
from being like 0 seconds to 2 

1331
01:10:16,400 --> 01:10:18,600
minutes in a way that makes 
sense. 

1332
01:10:18,600 --> 01:10:19,700
For users. 
You can show them like 

1333
01:10:19,700 --> 01:10:21,300
transparency. 
You can show them like connects 

1334
01:10:21,300 --> 01:10:23,700
can reach our Network, explore 
to show like track the 

1335
01:10:23,700 --> 01:10:26,200
transaction life cycle. 
And if something goes wrong, you

1336
01:10:26,208 --> 01:10:27,700
could surface, that really 
accurately. 

1337
01:10:29,200 --> 01:10:33,000
Whoo-hoo. 
So I didn't tell us what's 

1338
01:10:33,000 --> 01:10:36,800
what's next for connect. 
So what, what do you plan to get

1339
01:10:36,800 --> 01:10:39,900
done within the next year, or 
so? 

1340
01:10:41,600 --> 01:10:45,300
Yeah, the two biggest things. 
The team are is focusing on 

1341
01:10:45,300 --> 01:10:48,600
right now are the the launch of 
the a mark upgrade which is the 

1342
01:10:48,600 --> 01:10:51,700
upgrade that incorporates Nomad 
and moves towards this like, 

1343
01:10:51,700 --> 01:10:55,200
generalized messaging pattern. 
We already have that upgrade on 

1344
01:10:55,200 --> 01:10:57,600
Testament, or I guess there's 
three big things over from since

1345
01:10:57,600 --> 01:11:00,500
we already Have this upgrade on 
test that there are a lot of 

1346
01:11:00,500 --> 01:11:01,500
people already building against 
it. 

1347
01:11:01,500 --> 01:11:05,200
I think we announced the tested 
publicly last week. 

1348
01:11:05,200 --> 01:11:10,000
And since then, we've already 
had 131 router setup on the test

1349
01:11:10,000 --> 01:11:11,400
net. 
And then about 15 thousand 

1350
01:11:11,400 --> 01:11:12,800
transactions, which is 
incredible. 

1351
01:11:13,000 --> 01:11:15,300
It's mind-blowing that so many 
people have been interested in 

1352
01:11:15,300 --> 01:11:17,000
building on it and it 
experimenting with it. 

1353
01:11:17,200 --> 01:11:20,400
So, we're super excited about 
getting that live as fast as 

1354
01:11:20,400 --> 01:11:23,300
possible. 
And we, we have audit scheduled 

1355
01:11:23,300 --> 01:11:27,900
to begin starting in about think
about a week now, so, it should 

1356
01:11:27,900 --> 01:11:30,000
be. 
You like first like its second 

1357
01:11:30,000 --> 01:11:35,000
week of of June and then running
until like the start of July and

1358
01:11:35,100 --> 01:11:38,100
we should go live shortly after 
the other two main pieces. 

1359
01:11:38,200 --> 01:11:40,000
So that's that's a big part of 
the focus of like the 

1360
01:11:40,000 --> 01:11:42,600
engineering team and protocol 
team at the moment. 

1361
01:11:42,900 --> 01:11:44,000
And then the other two big 
pieces. 

1362
01:11:44,000 --> 01:11:46,400
Are we have a contributor 
program? 

1363
01:11:46,400 --> 01:11:48,800
That is ongoing. 
This is a way for people to 

1364
01:11:48,800 --> 01:11:50,600
start getting involved with 
working with the Canucks 

1365
01:11:50,600 --> 01:11:53,600
ecosystem and a big part of his 
that of this is that we want to 

1366
01:11:53,600 --> 01:11:56,400
take existing processes around, 
you know, running the router 

1367
01:11:56,400 --> 01:11:58,800
ecosystem in the growing it. 
Running the community and 

1368
01:11:58,800 --> 01:12:01,900
growing it, and things like that
and and spend them out to the 

1369
01:12:01,900 --> 01:12:05,900
community entirely. 
You know, like we want it to be 

1370
01:12:05,900 --> 01:12:08,700
the case that like our community
is self-operating. 

1371
01:12:08,700 --> 01:12:12,000
We want it to be the case that 
like, you know, routers or 

1372
01:12:12,000 --> 01:12:14,000
self-organizing to apply for 
Grants. 

1373
01:12:14,000 --> 01:12:16,700
They are working internally to 
improve the experience of 

1374
01:12:16,700 --> 01:12:20,600
operating in a router and like 
onboarding new routers and 

1375
01:12:20,700 --> 01:12:22,200
versus the core team doing 
everything. 

1376
01:12:22,600 --> 01:12:24,700
And so that has already kicked 
off. 

1377
01:12:25,200 --> 01:12:27,700
There are there's absolutely 
room for people to participate. 

1378
01:12:27,700 --> 01:12:30,800
So If you are a person outside 
of the US and you are interested

1379
01:12:30,800 --> 01:12:33,300
in working with connects, or at 
least just interested in 

1380
01:12:33,300 --> 01:12:34,800
participating and being 
involved. 

1381
01:12:35,400 --> 01:12:39,000
You can sign up at contribute 
connects to the network and and 

1382
01:12:39,000 --> 01:12:42,800
or tokens to do to basically 
work on helping us build this 

1383
01:12:42,800 --> 01:12:45,900
ecosystem. 
And then lastly, the last bin 

1384
01:12:45,900 --> 01:12:47,800
main focus is of course, our 
token lunch. 

1385
01:12:47,800 --> 01:12:49,700
So we announced about a month 
ago that we are. 

1386
01:12:49,700 --> 01:12:53,000
We are heading towards a 
releasing, the next token, which

1387
01:12:53,000 --> 01:12:56,000
is going to be a governance and 
stinking token in our Network 

1388
01:12:56,700 --> 01:12:58,000
there. 
Also other kind of token back. 

1389
01:12:58,300 --> 01:13:01,700
That we've been experimenting 
with and thinking about but we 

1390
01:13:01,700 --> 01:13:04,000
want to be like very 
conservative with the way that 

1391
01:13:04,000 --> 01:13:07,000
we Implement them because it's 
really hard to take back a token

1392
01:13:07,000 --> 01:13:09,000
model once you've implemented it
if that took him out as 

1393
01:13:09,000 --> 01:13:12,500
Incorrect and and we really want
to make sure that there's a lot 

1394
01:13:12,500 --> 01:13:15,700
of like Community input. 
Once the Dow goes live on it, 

1395
01:13:16,300 --> 01:13:20,100
but we're currently expecting 
that to go live within the next 

1396
01:13:20,100 --> 01:13:24,000
like month or so. 
We're currently working on like 

1397
01:13:24,000 --> 01:13:28,000
finalizing things like airdrop 
allocations finalizing. 

1398
01:13:28,100 --> 01:13:30,900
Things like, you know, the fight
like the Latin remaining legal 

1399
01:13:30,900 --> 01:13:33,700
pieces and things like that and 
like the rollout of the token 

1400
01:13:33,700 --> 01:13:35,300
itself and how it will be 
distributed. 

1401
01:13:36,600 --> 01:13:39,300
And of course, given market 
conditions and things, I noticed

1402
01:13:39,500 --> 01:13:42,500
we're thinking really carefully 
about how like making sure that 

1403
01:13:42,500 --> 01:13:45,900
we that, you know, community 
members are like treated fairly 

1404
01:13:45,900 --> 01:13:50,400
and that that, you know, people 
are getting materially rewarded 

1405
01:13:50,400 --> 01:13:53,300
for their work or materially 
like compensated for, for the 

1406
01:13:53,300 --> 01:13:55,500
things that they do in the 
ecosystem both now, and after 

1407
01:13:55,500 --> 01:13:57,900
the Dow goes live as much as 
possible. 

1408
01:13:58,200 --> 01:14:01,200
And that, you know, the, the 
market, you know, may end up. 

1409
01:14:01,200 --> 01:14:03,200
We may end up heading towards a 
market or things like that in 

1410
01:14:03,208 --> 01:14:09,500
the future. 
Whoo engine sounds like exciting

1411
01:14:09,500 --> 01:14:12,200
times. 
Yeah, looking forward to see. 

1412
01:14:12,800 --> 01:14:15,000
None of us are sleeping. 
What comes out of connects over 

1413
01:14:15,000 --> 01:14:18,100
the next couple of months. 
Yeah, and it's been a pleasure 

1414
01:14:18,100 --> 01:14:19,800
to have you on. 
Thank you so much. 

1415
01:14:19,800 --> 01:14:24,000
I really appreciate it. 
Thank you for joining us on this

1416
01:14:24,000 --> 01:14:26,400
week's episode. 
We release new episodes every 

1417
01:14:26,400 --> 01:14:28,500
week. 
You can find a subscribe to the 

1418
01:14:28,500 --> 01:14:32,200
show on iTunes Spotify, YouTube 
SoundCloud or wherever you 

1419
01:14:32,200 --> 01:14:34,500
listen to podcast. 
And if you have a Google home or

1420
01:14:34,500 --> 01:14:37,300
Alexa device, you can tell it to
listen to the latest episode of 

1421
01:14:37,308 --> 01:14:40,400
the epicenter podcast. 
Go to epicenter, .t V /, 

1422
01:14:40,400 --> 01:14:42,800
subscribe for a full list of 
places where you can watch and 

1423
01:14:42,800 --> 01:14:45,100
listen, while you're there, be 
sure to sign up for the 

1424
01:14:45,100 --> 01:14:47,100
newsletter. 
So you get new episodes in your 

1425
01:14:47,100 --> 01:14:50,900
inbox as they're released if you
want to interact with us guests 

1426
01:14:50,900 --> 01:14:53,800
or other podcast listeners, You 
can follow us on Twitter and 

1427
01:14:53,800 --> 01:14:56,100
please leave us a review on 
iTunes helps people find the 

1428
01:14:56,100 --> 01:14:57,800
show and we're always happy to 
read them. 

1429
01:14:58,600 --> 01:15:01,300
Well, thanks so much and we look
forward to being back next week.