UMA & Across: Optimistic Oracles & Intent-Based Bridges for Unifying Ethereum - Hart Lambur - Epicenter - Learn about Crypto, Blockchain, Ethereum, Bitcoin and Distributed Technologies

Episode Transcript
Available transcripts are automatically generated. Complete accuracy is not guaranteed.
(00:00):
Our initial thinking was we should write financial contracts
on a blockchain, it makes them globally accessible.
Whereas financial contracts in Tradfi, you know, you have to be
part of the legal jurisdiction of country XYZ.
Well, we need an Oracle to be able to resolve the data about
like what the output outcome of this financial contract should

(00:22):
be. We are inspired by things like
Vitalik's Shell and Coin blog post from 2014 and various like
game theoretic concepts and crypto economic concepts.
But the core idea is pretty simple.
Anyone on the blockchain can propose a statement as true, and
then there's a challenge period.And anyone else on the
blockchain during that challengeperiod could say, I disagree.

(00:43):
There's bonds and there's incentives here to both propose
correctly and to dispute correctly.
And there's penalties if you propose incorrectly or dispute
incorrectly too. Did is we're like our whole MO
is we want bridging to be a 2 second or less experience.
We want it to be fast and cheap,but we think like the speed is
critically important. Welcome to Epicentre, the show

(01:05):
which talks about the technologies, projects and
people driving decentralization and the blockchain revolution.
I'm Frederica Ans and today I'm speaking with Hart Lamper, who
is the Co founder of OMA and a Cross Protocol, which are two
interrelated projects in the wider Ethereum space.
So Uma is a decentralized optimistic Arkle and the cross

(01:26):
is a bridge that in some flavours uses Uma under the
hood, but we'll get it to that in in just a second.
Before I talk with Hart, let me tell you about our sponsors this
week. If you're looking to stake your
crypto with confidence, look no further than Course one.
More than 150,000 delegators, including institutions like Bid

(01:47):
Go, Pantera Capital and Ledger Trust.
Course One with the assets. They support over 50 block
chains and are leaders in governance on networks like
Cosmos, ensuring your stake is responsibly managed.
Thanks to the advanced MEB research, you can also enjoy the
highest staking rewards. You can stake directly from your
preferred wallet, set up a whitelabel note, restake your assets

(02:07):
on Eigenia or Symbiotic, or use the SDK for multi chain staking
in your app. Learn more at Chorus .1 and
start staking today. Hey guys, I want to tell you
about Gnosis, a collective of builders creating real tools for
real people on the open Internet.
Nosis has been around since 2015.
In fact, it started as one of Etherium's very first projects,

(02:28):
and today it's grown to a whole ecosystem designed to make open
finance actually work for everyday people.
At the center of it all is NosisChain.
It's a low cost, highly decentralized layer, one that's
compatible with Etherium and secured by over 300,000
validators. So whether you're building a
DAP, experimenting with Defy, orworking on autonomous agents,
Nosis Chain gives you a solid, neutral foundation to build on.

(02:51):
But Nosus is more than just infrastructure.
It's also tools that people can actually use.
Like Circles, for example. Let's anyone issue their own
digital currency through networks of trust, not banks.
And then there's Metri. It's their smart contract wallet
that makes it easy to access circles, manage group
currencies, and even spend anywhere Visa is accepted thanks
to their integration with Nosus Pay.

(03:14):
All this is governed by Nosus Dow, where anyone can propose,
vote and help guide the network.And if you want to get involved,
running a validator is super easy.
All you need is 1 GNO and some basic hardware.
To learn more and start buildingon the open Internet, head to
gnosis dot IO Gnosis Building the Open Internet one Block at a
time. So cool, hot, it's so nice to

(03:37):
have you on. Thank you so much for having me,
good to be here. Incredible as it sounds, you've
never been on this podcast before, so your Co founder
Allison has been on. So maybe before we kind of dive
into kind of like all the awesome stuff that you're
building. Tell us about who you are and
how you got here. Sure.

(03:58):
Yeah, You know, I was looking back, I was actually trying to
remember if I'd been on Epicenter before like years ago.
But you're right, it was Allison, my Co founder that that
that was on here. PLDRI studied computer science.
I then worked in financial services at Goldman Sachs as a
bond trader like U.S. Treasury bonds in the financial
crisis. Allison was two years junior to

(04:23):
me and worked beside me for fouryears there, something like
that. And we were very closely
together and that's how we got to know each other in the 1st
place. Trading bonds during the
financial crisis, U.S. Treasuries during the financial
crisis was super interesting. It's not my background, but I've
learned a lot about finance. I learned about market
structure, learned a lot about actually incentive structures

(04:44):
and what incentivizes people come back to that.
I left to do a fintech business that weren't kind of sideways
got acquired by NASA manager four years later and then was
full time in crypto starting beginning of 2018.
And I recruited Allison to work with me on this decentralized
finance idea. Before D5 was a term, if we go

(05:05):
back to 2018, people hadn't really thought about that as a
concept yet. And Frederica, you'd remember
this from like Gnosis days too. It was just kind of like it was
all sort of researchy stuff, right?
Like what could, what kind of financial applications or
financial ideas could be built on smart contract platforms and
on Ethereum? Yeah, absolutely.

(05:25):
So kind of the thing that you guys started back then was
called Universal Market Access or UMA for short.
And you actually started with synthetic assets.
How how I mean you came from a trading background.
So kind of, I guess it kind of like it, it checks out.
But how did you land on this andwhen did you kind of decide to

(05:47):
kind of pivot to kind of an Oracle?
Well, it's, it's, it's interesting to think about it
because in some ways we definitely pivoted and in other
ways it was just like kind of all the plan the whole way.
The, the way to think about thisor the way I like to think about
it is our initial thinking was we should write financial

(06:09):
contracts on a blockchain that makes all the sense in the
world. It also, it makes them globally
accessible. Whereas financial contracts in
Tradfi, you know, you have to bepart of the legal jurisdiction
of country XYZ to, to have access to that financial product
or service. So you know, the name universal
market access was all about how do we make finance globally

(06:31):
accessible? Well, we need a enforcement
mechanism that is globally accessible.
A blockchain actually can do that pretty well with economic
incentives. OK.
So we like this idea of financial contracts.
You could call them derivatives.Derivatives are just financial
contracts, right? But we wanted to do that on a
blockchain. And we're like, well, we need an
Oracle to be able to resolve thedata about like what the output

(06:55):
outcome of this financial contract should be.
Concrete example, like you and Ido a binary bet on whether the
price of Bitcoin will be above or below 100K.
We need to know whether that's true or not, etcetera.
So that's where we like came up with this Oracle design that we
were super excited about early on.
Then though, we needed a use case and we're like, OK, it's

(07:17):
super early days. Like we need something for
somebody to use. It's super early days of crypto.
Nobody wants to like trade financial derivatives yet.
That's like too sophisticated. We were like, let's make tokens.
People like tokens. Let's make tokens that look like
financial contracts. There are derivative contracts,

(07:38):
there's synthetic make assets iswhat we did, synthetic assets
that track some other underlyingobject and we can use our Oracle
to power that. So it's kind of the path there
of how we got into into that space at the time.
Yeah, super interesting. It's funny how kind of sometimes
you start doing one thing and then kind of like you, you, you

(07:58):
need to build like part parts tokind of power this.
And then kind of like the, the, the parts that power this kind
of become your, your main thing kind of later.
And this kind of happened again,right?
So kind of like you, you guys have since launched a cross,
which also kind of came out fromthe UMA ecosystem and across is
a bridge kind of like which which is already kind of clear

(08:20):
from the name. But what prompted this?
So honestly, we wanted more use cases for the Yuma Oracle and we
did. Basically it was an internal
hackathon again. There might be like Gnosis
parallels here too, because you guys also came to spawn up a
bunch of ideas along the way. And actually we always kind of
looked at you guys for inspiration that way, but we

(08:43):
wanted more use cases for this UMA Oracle.
And we're like, OK, the synthetic assets, they weren't
really taking off. This is, you know, four years
ago, 3-4 years ago. People want to trade crypto
assets, not, you know, syntheticassets.
That might actually be changing right now.
We'll see. But but we're like, we have this

(09:04):
really interesting Oracle that can give you give you data on
anything. It it can even give you data on
what's happening on an L2 fasterthan the seven day bridge is
going to let you get data from that L2.
And we actually use this as an internal hackathon to build a

(09:24):
fast exit bridge from optimism. It went One Direction only.
It went it only let you get off optimism.
This is the first internal hackathon.
And then we're like, yeah, you know, there's something here.
And then we thought about it a lot harder, came up with this
these early like intent based designs, which I'm sure we'll

(09:44):
get into and realized that we had a really compelling product
in this super fast intent based bridge to connect mostly EVM
chains and then launched across as like something that used UMA
in the wild. Yeah, super interesting.
Maybe maybe because kind of maybe we go sequentially here.

(10:05):
So maybe let's talk about Uma first.
So kind of Uma, you already alluded to this, so kind of it's
an optimistic article. So what does this mean and how
does it differ from more traditional ARCA?
It's like chain link. I mean, chain link does a few
things now too, to be fair to them.
But the, the classic version of chain link is we're going to

(10:27):
have a, a series of nodes or some, some set of nodes write
price data to a blockchain. And so it's, it's very
constrained in that it will likeonly write the price data that
those nodes know to write. Works great for Bitcoin prices,
Ethereum prices, that kind of stuff.
OK, cool. But we were trying to solve the

(10:48):
generalized problem of we want to get any bit of data onto any
bit of verifiable data onto a blockchain.
And we're like, OK, well, we need a different system to do
this. We are inspired by things like
Vitalik's shell and coin blog post from 2014 and various like

(11:09):
game theoretic concepts and crypto economic concepts.
But the core idea is pretty simple.
We say, hey, anyone on anyone onthe blockchain can propose a
statement as true. So they could propose, we'll
take an election. They could propose Trump won the
election and then there's a challenge period.
And anyone, anyone else on the blockchain during that challenge

(11:30):
period could say, I disagree, right?
First step, the happy path, the optimistic path is nobody
disagrees. And so then that, that that
proposal gets taken as true. And there's, there's bonds and
there's incentives here to both propose correctly and to dispute
correctly. And there's penalties if you

(11:52):
propose incorrectly or dispute incorrectly too.
So we have incentives lined up there.
But it's a very simple kind of challenge game where anyone can
say this is what I know to be true and anyone else on the
blockchain can say I disagree. That's that's the core concept.
Walk me through what happens if I post an untrue statement and

(12:14):
someone calls me out on it. How how I assume kind of I get a
chance to kind of redeem myself or prove that kind of like what
I stated initially was actually true or how how, how, how does
is there some sort of escalationmechanism here?
Yeah. So you don't necessarily get a
chance. You and everyone else can decide
who's right. But like, let's let's go
concretely. So Fredrique, you propose that

(12:38):
Harris won the election. We'll use that example.
And you have to post a bond to do that.
The bond can be a parameter of the protocol of the system.
But you post a bond to say do that.
Let's say it's $1000. And then I can be like,
actually, I disagree with you. I think that's untrue.
I post a matching bond of $1000 to dispute you and say this is

(13:00):
untrue. OK, so first thing that Ooma
does is now that there's a dispute that data won't get used
in the underlying contract, we're going to have to wait.
We wait until somebody proposes in a way that doesn't get
challenged to use that data in the underlying contract.
So this is mostly true. So if it was Polymarket right

(13:22):
now, Polymark would be like, OK,we we're not going to use your
proposal that Harris one. We're going to wait for another
proposal later on, but we still need to resolve between two of
us who was right to figure out where we get those bonds.
Do the $2000 worth of bonds go to you or do they go to me?
And so then this is where we lean into like Vitalik's

(13:43):
shelling coin blog post ideas where and this is also a lot of
concepts from Auger and Gnosis and early prediction market type
stuff too. But we go and we say to all our
token holders, they, they go through a 2 step voting process
where they vote in secret what they believe is true, whether
your proposal or my dispute or it was correct.

(14:07):
And they, they, they vote in secret and then they reveal all
at once. And the game theory and
economics of this design are such that you're incentivized to
vote your own beliefs, your own truth, and the majority will get
rewarded with with a reward at the expense of the of the
minority that voted against the majority outcome.

(14:30):
And so we use this shelling point concept to resolve who out
of the two of us was correct by having this distributed
decentralized voter base here. OK, there's, there's several
super interesting things here. So kind of is it possible that
kind of like sometimes there aresituations where you are
incentivized to actually vote against your beliefs just

(14:53):
because you know what the other people's beliefs are like?
So kind of for instance, I give you, I give you, I give you an
example also say the COVID lab hypothesis, right?
So kind of like early on, kind of like there was there was
already very vocal kind of minority who kind of who were

(15:13):
who was advocating for this. And kind of as time went on,
it's turned out that kind of like they weren't crazy.
And maybe maybe it, it, it is actually kind of a lab sort of
thing. But someone who would have known
kind of like in the very beginning of COVID that this
kind of like this, this lab hypothesis was true.

(15:34):
Maybe because kind of like they were there on the ground or
maybe because it was them or whatever they were involved in
covering it up or, or however they kind of come to know this,
they would still have been incentivize to kind of vote
against what they truly believe because they know that this is
not a a consensus narrative, right?

(15:57):
Yeah. I mean, I think you picked a
very, very, very interesting example of where I think the
like, I think if you ran a long term prediction market over like
the COVID lab leak theory, like you didn't let it resolve and
you kept kept letting it run, I think you'd see that prediction
market move a lot over, you know, a four year period, right?

(16:20):
So it's a really, really interesting example.
What I would say is in, in theory, a voter, you can't trust
what other voters say they're going to vote.
They actually have an incentive to frankly lie to you because if
they get you to vote in the minority, they get a bigger

(16:42):
reward if they're the majority. So there is this like a
purposefully built PvP kind of mechanism within the voting game
itself where other voters are supposed to.
Like they literally have the game theoretic incentive to tell
you that they're going to vote the opposite of how they
actually do vote. And so, you know, the, the

(17:05):
theory behind this is if you understand how this all works
and or if you don't, you're supposed to just be like, OK, I
don't know what the noise out there is saying.
I'm going to do my own research,come to my own conclusion, and
vote my own beliefs because I don't really know at all with
any kind of certainty what others are going to say.
Now, there's a whole bunch of probably very interesting, like

(17:27):
philosophical and theoretical thoughts here too.
Like again, the lab leak exampleis something that I think is
fascinating because, you know, personally, I was, I thought
myself that the lab leak theory was kind of crazy early on.
And then my own beliefs evolved over time.
And now I like, I probably have to do a bunch more research to
come to my own beliefs, but I don't think it's crazy anymore,

(17:48):
let's put it that way. So it's a, it's a very
interesting example. But at the point in time, I
think at any point in time when these votes come on, voters
really do have the game theory to vote their own true beliefs
because they don't know what other people are actually going
to do. What happens if you don't vote?
Are you penalized? Yeah, you penalized, you

(18:08):
penalized less, right? So the penalties here are also
they're parameters of the system.
There's probably a lot more modeling we can do to figure out
how to optimally set them. But the penalties aren't like
100% or not. It's not like I vote and I lose
all my voting tokens if I vote incorrectly.
Like I we want to design the penalties so there's a strong

(18:30):
incentive to do your own research and vote correctly.
And we want to design the penalties so there's a strong
incentive to have people continue to vote and show up all
the time, but not so much of an incentive that, you know, if I
miss a vote or two, it's so painful that I exit the system
and stop participating. OK, that's fair.

(18:52):
So let's go back to the to the Harris example.
So I posted the Harris one the the presidential election
statement. You contested this and kind of
there was a vote that kind of confirmed that you're right.
Is this statement now kind of inthe in the in the negated form
usable kind of as an input for smart contracts or is it is it

(19:16):
tainted and we have to have a new new vote?
This is this is up to this is upto the integrator that wants to
like use this Oracle like they could go either way.
I prefer the design because thisvoting process also takes a
while, right? So one of the things that we've
seen with Polymarket, for example, is somebody will

(19:37):
propose an answer. They often they propose the
answer too early. They're like like a sports game
is a good example. They propose that someone's
going to win the sports game, but they propose like 5 minutes
before the end of the game. And you're like, even if that
team they proposed did win, you kind of can't be like we can't
say like it's OK to propose 5 minutes early.
Like what? It could have turned around,

(20:00):
right? So.
That will get disputed and it'llgo through this voting process,
but we don't want that that Polymarket market to sit there
and wait for this resolution process.
So we'll have somebody else propose a second proposal that
doesn't get disputed because it's after the game completed
and it has the right answer. So that's like an implementation

(20:21):
decision of like how Polymarket would use the Oracle in this
example. I prefer it.
I prefer the idea of you only take as truth undisputed markets
that are not tainted and the, the dispute process, sorry, the
voting process is really to resolve disputes and like where
the bonds go, I prefer that cause the economic security

(20:44):
behind that is like much, much deeper in many ways.
But it's a primer. It's it's up to the integration
decisions of the protocol. OK.
But in in that in that design, you could have kind of like say
500 statements that kind of speak to one question and 499

(21:05):
say no one says yes, it still get it goes kind of like
unchallenged somehow because people missed it.
And despite the fact that almostall of them kind of .1 way you
you could you would you don't actually have to wait for kind
of like any dispute to be resolved.
You can already kind of use the one yes statement to resolve

(21:28):
right? Sorry walk me through this.
How do you where the 500? So there's, there's so kind of
say there's 500 people kind of like post an answer to post a
statement who who won the election.
So say 500 kind of say Harrison,kind of like 499 of those get

(21:48):
contested. And one just kind of gets missed
by by by kind of the because kind of like there's, there's
also attrition here, right? Kind of for the, for the,
because it's an optimistic system.
Yeah, there's sort of a DOS vector is kind of what you're,
you're, you're kind of like, yeah, spamming the system to
kind of overwhelm it. Yeah.
So I'm going, I'm skipping over some details like I should in

(22:13):
polling markets implementation at least you couldn't have they
wanted to let you have 500 proposals for the same market
for these same reasons. So it's kind of like anyone can
propose the first one, anyone can propose the second one.
After the second proposal, we actually wait for the resolution
of the voting cycle. And then other people, there's
like stuff that we do to, to kind of makes your eyes are

(22:36):
focused on the right markets because you're, you're right.
Otherwise you kind of have like you can kind of just spam and
overwhelm people. And if there's actually humans
voting on this, there are practical like human, human
bandwidth constraints about whatyou can take care of, which, you
know, like as polling, market scaling and other use cases are
scaling. And you and I talked about this

(22:57):
very briefly out of the podcast.There's lots and lots of use
cases of where LLMS and AI can potentially scale this much
better, which I find super compelling and interesting.
But yes, your your example is a fair one.
And we have to put constraints around this this too.
Can I grief kind of the market creators or the people who have

(23:17):
market money on the market by creating 2 conflicting or two
wrong statements and kind of like just making sure that kind
of they incur the opportunity cost of not being able to kind
of get their capital out of the market?
Polling market does not allow permissionless market creation
at right now make that I I can'tspeak for them.

(23:40):
I don't want to speak for them, but like one reason might be
this problem, right? And I if you go back and I think
you ELO, you don't you experience with this, but we
look at Auger and other examplesand you know, if you have a
bunch of very similar markets, it also leads to this kind of
fragmentation of attention problem.
I think it's a hard problem to solve.
Again, I think you could going forward, if, if I were to design

(24:05):
like a permission less prediction market kind of system
here, I think you could use an AI to validate like, are these
markets similar and then not allow the creation of markets
that are like super close. But I think these are, these are
all the problems that productionmarkets like have to solve to
keep scaling and growing. So I think you, you know, you
have a lot of experience and personal interest in this, I

(24:27):
think. And yeah, it's it's a good
question, but that's why Polymarket doesn't let anyone do
it right now. You could also kind of tie the
amount of the bond you have to put to the amount of money in
the market. So they're kind of like you
can't do it at a flat rate. You kind of it, it, it at least

(24:50):
kind of like costs you kind of aproportion of the funds you're
tying up well. I was just going to say the last
point I'd make. The The thing is interesting is
like with prediction markets. So again, the UMA Oracle does a
lot more than just prediction markets, but that's what we've
been. We're really the like kind of
the only Oracle type being used in production at scale that does
prediction market type stuff. But the thing that I found

(25:13):
interesting over the years and years of kind of doing this is
there's the theory and then there's like the practical
implementations. And there's a bunch of
heuristics here too that I thinkare like where it's not obvious
from a pure theory or research perspective.
You've got to like do this kind of like glue and Band-Aid type
stuff to to keep things working effectively.

(25:36):
And you know, this is where I will give like Polymark deserves
a lot of credit for figuring outhow to actually grow and scale
these markets. And even since the election,
they have figured out how to have many, many more markets
than they did six months ago andhave it like mostly work.
Yeah, yeah, I, I agree. What's your take on fine print

(26:01):
driven outcomes on friction market?
So for instance, kind of on auger kind of invalid outcome,
what was kind of a huge problem.And when that kind of comes to
mind. Well, I actually think kind of
like Uma worked really well as an Oracle was kind of do you
remember that submarine that kind of sank and kind of there

(26:23):
was a market on polymarket with a submarine be found and clearly
it wasn't found because kind of like it imploded, right?
But kind of somehow kind of, butclearly that was not the intent
behind the market. So, and UMA actually resolved it
to, yes, it was found and kind of I, I remember there was kind

(26:44):
of some upheaval on, on crypto Twitter about whether this was
the right call. I think, I think personally,
it's the call that I would have made because clearly that was
kind of the intent behind the market, but it's really
difficult. So what what's what's your take
on this kind of should Arcas weigh context or should they

(27:04):
just strictly enforce definitions?
Well, you, you can't strictly enforce definitions because the
English language or any languageis imperfect, right, Frederick
Like, it's so funny you brought out that example because I, I
agree with you personally. And like, you know, in the
moment, I don't have any opinionand I don't vote or participate

(27:25):
in these markets myself at all. But there was a bunch of people
that are trying to argue that, you know, they found pieces of
the submarine, but they didn't find a big enough piece of the
capsule to fully confirm it was it imploded, right.
But like it, it was like a very nuanced reading of the rules

(27:47):
that just didn't capture the spirit of it at all.
So yeah, the thing that is superinteresting about prediction
markets, if we go back to call them financial contracts,
they're financial contracts, butthey're binary.
One side wins 100%, the other side loses everything.

(28:08):
And what that means is that if there's ambiguity in the rules,
the losing side has a really, really, really big incentive to
try to be loud and proud and tryto scream as as loudly as they
possibly can. Hey, hey, we're right, the other
side's wrong. Or if they lose, they also have

(28:28):
an incentive to scream. The system is broken.
Scam manipulation, like all thisother kind of attacking stuff,
which, you know, sometimes I'm on the receiving end of, which
isn't particularly fun. But like the game theory here is
like, look, if, if it's something with some ambiguity,
one side is going to be really upset because they're losing all

(28:50):
their money. And that's human nature, right?
So what's my take on this? My take on this is that it's
tricky. And like you, Polymarket has a
process now of issuing clarifications around markets,
which are also sometimes very imperfect.
And you know, they don't ever want to be the one just like
deciding the market outcome heretoo.

(29:12):
But I think we really try to usethe showing point concept to
come to the least wrong answer is the way I look at it.
Like what is the least wrong answer that we can offer to to
resolve these markets? Because you also touched on
another point that is very nuanced and not many people know
of or think about. But if you go back to Auger

(29:34):
days, Auger had a lot of invalidmarket outcomes.
So it just said this market isn't clear enough, we're just
going to not respond. And Uma and Pauli market
generally don't do that. We also a.
Terrible user experience, right?So kind of yeah, yeah.

(29:57):
Because it's a terrible user experience.
Exactly right. You're like, hey, I'm a
prediction market trying to predict the future.
And then you're like, you kind of like can't, can't answer it
right. That's not good.
And so, but then that that said,that forces the Oracle system to
resolve slightly ambiguous outcomes too.

(30:20):
Yeah. Can you give us an idea of how
often disputes happen, kind of in absolute and relative terms?
Yeah, the dispute rate is less than 1% of all proposals.
We're actually putting a lot of effort into getting it down

(30:41):
more, and there's like a very cool project we're working on
that's not far away that I thinkcan actually lower it by an
order of magnitude. Too many of the disputes, like
I, I need to double check this, but it's something like 70% of
the disputes are actually from people proposing too early.

(31:03):
So they actually put the market up at before they should, which
is fascinating. And yeah, it's really
fascinating too that that happens.
So you can say that it's something like .3% of all
proposals are like legitimately disputed that aren't like too
early, something like that. And the the system is currently

(31:27):
processing between 250 and 500 proposals a day like market
resolutions a day, which is up alot from six months ago.
Give us an idea of kind of who uses Uma's Arca, Yeah.
So the biggest user by number ofproposals by far is Polymarket.

(31:50):
They just, they're, yeah, they've kind of achieved escape
velocity in the prediction market space here.
Across, we'll talk about that maybe transition soon.
Across uses it also to validate this like complex data
structure. So it's a very different use
case. We're basically being like,
here's this complex data structure that anybody can

(32:11):
recreate, but it would be hard to do on chain.
Anyone can do it off chain easily though.
And Across uses Zuma to validatewhether that data structure was
created correctly or not. And then we have other like
interesting use cases that are experimenting like story
protocol, they're kind of doing IPIP stuff and they use the

(32:36):
system to resolve some IP disputes.
That's just getting going. And then there's a like a long
tail of smaller prediction market adjacent use cases too.
Super interesting. Maybe before we kind of
transition over to across what what talking about kind of like
the optimistic security assumptions, where would you say

(32:58):
they work well and where do you think kind of like maybe they're
not fragile, but we can do better?
I think they work well in markets where there are lots of
eyes on them, and eyes could be humans or machines too.
We'll come back to that in a second.

(33:19):
They also work well where like false outcomes are very obvious,
right? So if we go back to the Trump
Harris election, there were a ton of eyes on that market and
the outcome is actually pretty obvious.
Maybe it's not obvious to resolve it like right in real
time, but it's obvious. Like if you if you, if you say

(33:42):
this is too early or I shouldn'tdo this yet and you wait till
there's like enough pulling clarity, it's pretty obvious,
right, what the outcome is. So in those use cases, I think
these optimistic systems work really, really well where things
get scary, right? It would be like, OK, there's so

(34:02):
many markets. This goes back to kind of your
griefing example. There's so many markets or they
have small enough value in them or for whatever reason, there's
not enough eyeballs watching them.
Then I think there's like a legitimate question about like,
wait, is there anybody around todispute this if somebody does
try to sneak a battle come through?
However, this is where all of like the Super intelligences

(34:26):
that people are working on become extremely useful and you
think about what an LLM can do. I don't think it completely
replaces humans yet, but it certainly gives us a machine to
put a lot more eyeballs on a lotof things, and I think that that

(34:47):
actually strengthens many of theoptimistic verification
assumptions in an extremely useful way.
Yeah, I think that's that's a, that's a fantastic answer.
So you guys, you already talked about this briefly in the
beginning. So you guys actually started the
bridge kind of initially kind oflike as a consumer of Uma, the

(35:11):
Oracle, how maybe kind of like the, the, the housekeeping
first, how did this work in terms of ownership structure?
So kind of these are two token projects.
So kind of like how, how, how are the tokens related?
And kind of like how, how did your first set of token holders
feel about kind of you guys working on a second token

(35:35):
project? I mean, I'm very much asking
kind of not for a friend. So kind of we've done this
before too, so. We looked at you guys for some
of this stuff a little bit too and it was it was interesting.
So that's so the way we looked at it is UMA users were like are

(35:57):
happy to have other users of UMAand at least at the time when we
did this, it's like, OK, that makes sense.
And then we made an attempt to launch the across token in a
very fairway. And there's lots of actually
like lots of really interesting decisions that with more like

(36:19):
looking at them in hindsight, maybe could have done things
differently too. We, we in, in some ways I feel
like the across token was rushedout because we actually needed,
we needed a token to gather someLP funds to help make the bridge
usable. Like we needed token emissions
to incentivize people to depositinto our protocol.

(36:43):
And we actually came, put this out just a little bit before
people sort of started doing thepoints thing, like the points
program thing. And it's funny because I think
first of all, I wish we inventedthat idea, which we didn't.
But if we had the points idea, we may have delayed the token
much longer and used points to help incentivize some of the

(37:04):
behavior we needed. Anyways, neither here nor there.
We did try to put the token out in a very fairway.
We tried to have a fairly broad AirDrop and the like.
The kind of UMA team actually had Pretty Little ownership in
the across token, at least earlyon too.

(37:25):
And so nobody really had a problem with that.
That's the way I I'd answer that.
Yeah, it's just kind of like we're building cool stuff in the
space. It's related.
It's good for both projects. It's good for both teams.
That's good. So maybe let's talk about how
across used to work. So across used to use, you know,
a purely optimistic model. Let's talk about this first and

(37:48):
then kind of like how you've recently kind of upgraded it in
the ZK RAM. Yeah, so you know, your listener
base is pretty nerdy. We'll take.
That as a compliment. A a massive compliment.
You know, they're not the not the crypto curious folk that
like are are we can go deep on this stuff.

(38:08):
So what does a cross do? Let's actually start there, if
that's OK. So a cross is an intent based
bridge. The way I, I explain this, and
this is this is the basic explanation, but I want it for
blockchain A to blockchain B. We'll make it arbitrary to base.
How can I do that? The naive way is I deposit
something on Arbitrum, I send a message to base, and then I

(38:33):
release funds on base to the user and that's all well and
good. That's how I, I think a lot of
like first generation bridges work.
And the problem with that is I need to wait for finality or a
high degree of finality on blockchain A before I send that
message. Cuz if that message is wrong,
I'm gonna like release funds from a pool or something or mint

(38:56):
tokens that aren't backed if there's a reorg on A.
So I have to wait for finality and then I have to send that
message and that's like a slow process.
So what a cross did is we're like our whole MO is we want
bridging to be a 2 second or less experience.
We want it to be fast and cheap,but we think like this speed is

(39:17):
critically important. So we're like, OK, well, we have
finality constraints on the origin chain that just are not
going to let us do stuff in 2 seconds with at least with like
other people's money. However, we could introduce 1/3
actor, a solver, or a relayer, same term that is sophisticated

(39:40):
enough to price the reorg risk or understand the risks they're
taking, and we could use them tofront money to the user on the
destination chain very quickly and then they get packed.
They get paid back later after we verify the fill habit.
So this is the intent based model where a user effectively
deposits on chain A, they deposit into escrow, A race

(40:02):
starts for the third party solver to fill them on chain B,
Third party solver fills them onchain B very quickly.
And then user goes on with theirday, they're happy, and then the
protocol says verifies that fillhappened before releasing the
funds back to the solver. Yeah.
I mean, it's a slightly different design than many
optimistic bridges where kind ofyou say, OK, look, you kind of

(40:24):
you, you kind of you bridge optimistically and there's kind
of there's a message sent acrossthat bridge.
And then kind of on the other side, kind of like you kind of
you, you someone, someone kind of fronts you the liquidity to
kind of already use the funds onthe destination chain for a
couple of basis points until kind of the optimistic time the

(40:49):
time period has has run out, right.
So kind of how, how would you kind of pit these against one
another? I mean the there's no optimistic
part in what I just described. We can go and maybe the
verification of this, but the fact is user wants funds
unencumbered on the destination chain.
So we just use the third party solver to just give them their

(41:10):
like give them money and the user goes and they have the
money and they can do whatever they want.
And there's no chance of like a rollback.
They just, they have the funds, right?
So it's very clear, like there'snothing weird going on there.
And the solver just has some risk that if there's a reorg on
chain A, there's some risk of ruin that they like lose their
funds or something like that too.

(41:31):
But they're very good at pricingthis and we use market forces to
price this reorg risk all over the place.
And so it really does allow us to have two second bridge
experiences between all the major L twos with like very,
pretty low fees, very low. Fees, can anyone be a solver?
So kind of like, say, for instance, I, I had dirty funds

(41:53):
that kind of like I wanted to distribute amongst kind of like
innocent people, kind of say from some sort of hack.
Could I just kind of like send this to, to, to, to people on
the destination chain and kind of reclaim the, the, the clean
fund that they initially deposited?
Man, you're asking me like the hard questions here.
Solving is permissionless with like asterisks and caveats.

(42:19):
We have not had any rogue or like any dirty solvers
participate in our network and we do have ways to prevent them
from participating in our network while still maintaining
the permissionless ethos. I don't know that I actually
want to share all the ways that we have to prevent them for for

(42:39):
reasons, but it's it's a very good question that we've
actually gone pretty deep on. It's, it's, there's also not a,
it's not a very good mechanism to wash funds either.
Like it's all pretty, you have to compete against our other

(43:00):
solvers that are very competitive too and win.
So it's it would actually require a lot, a lot a lot of
expertise to do this at any typeof scale too.
But no. That's all laundering, kind of
like laundering is, is an incredibly labour intensive
business, right? Kind of like This is why Lazarus

(43:21):
has like 20,000 people doing this.
Is it 20,000 now? Well it's 25,000 in total, but
kind of like a majority of them are are supposedly doing
laundering so. Yeah, Yeah.
OK. Well, for our friends out there,
I'm not going to share how we can prevent this, but we can
prevent it I think in a pretty in a fairly robust way while

(43:44):
also securing the ethos of permissionless participation in
our network. And we haven't seen any evidence
of this today. OK.
How does the pricing work? So kind of like I'm, I'm, I
mean, I kind of there's lots of things that kind of I have to
factor in. So kind of like how how often
can I use my funds one way or the other?

(44:04):
Kind of like is there a preferred way of bridging?
Kind of do I have to kind of route them kind of back the long
way or kind of like, yeah, so kind of all of these things.
So kind of, I assume kind of every solver kind of does this
kind of like on on their end. But do you have any any idea of
kind of like what goes into thispricing mechanism?

(44:28):
Yeah, I have a lot and it's super nerdy and super fun, but
you can actually step back and be like, OK, so filling this
intent again, go back to our example from A to B, from
Arbitrum to base, filling this intent, we're actually kind of
competing on 2 dimensions, competing on price and competing
on speed. Who can do it fastest.

(44:51):
And what we've chosen to do to date is actually just compete on
speed. So our API, you know, you can
set your own fee. It's permissionless that way.
But our API will tell most usersthat use like our API or use our
front end, we will suggest a feeof what the the user should
submit. And then all the solvers are

(45:11):
purely competing to win that feeon the destination chain
competing based on speed. And we've done this because we
really tried to sell the fast user experience.
And so we definitely in in many ways we charge well
definitionally we charge too much.
We charge more than the marginalcost that like purely

(45:32):
competitive price of what it would take to fill on the
destination chain because we aretrying to have all the solvers
compete on speed and we've gotten our own heuristics to to
kind of set that price in a way that we think is going to lead
to good competition on the the fill.

(45:52):
There's a very, very cool idea that it's probably going to be a
white paper there where we like can kind of do both that not
quite ready to talk about, but Ithink there's very cool ways
that we can do both that are arestill have a good UX here too,
which I'm excited about. But yeah, that that's what we're
doing today. And you know, setting that fee,

(46:12):
the fee is a matter of gas costson origin and destination chain.
Our gas costs of our system are very lightweight because we
batch the verification which we have.
We can talk about the UMMA component here too.
So our gas costs are extremely lightweight both sides, but
there's still a gas cost. So that goes in part of the fee
estimate that goes into the fee estimation.

(46:36):
The other costs would be, OK, how long before we repay the
solver? So they're making a loan How
what's the cost of capital? How do we manage that?
Or the third cost would be rebalancing costs.
So user is solver has to front money on this chain.

(46:57):
How easy or cheap or how long does it take to rebalance funds
on and off of that chain, which is a very difficult thing to
measure, but you can kind of approximate it.
And then the 4th cost would be the 4th cost we actually get to
ignore. The 4th cost would be like,
what's the risk of a reorg on the origin chain, which would

(47:21):
cause the solver to not get repaid?
That actually gets priced into the speed competition.
So solvers can be like, OK, how many blocks of finality on the
origin chain do I need to see the users deposit transaction
into escrow before I feel confident that that the risk of
reorg is low enough for me to actually take this risk on.

(47:43):
So that's that one kind of gets lumped into speed here.
And so we get to think that's pretty pretty deeply.
It's pretty fun. But that's that's the the nerdy
answer to your. That's kind of like a reverse
Dutch auction, but yeah. And you kind of you send the,
the you send the bid at the at the time point where you feel

(48:03):
like kind of the the cost kind of balance.
So you kind of recently switchedto AZK bridge for or AZK
verification mechanism for part of the bridge experience, namely
to BSE, right? Correct.
So we've added ZKZK magic and itreally is magic.

(48:27):
We've added it to part of the cross intent verification, let's
call it the settlement system here.
So I look at a cross and all intent systems in three layers.
There's like the auction layer of who's going to fill the
intent, there's the solver layerof who's the solver that's

(48:48):
actually doing the work to fill the intent.
And there's the settlement layerwhere funds go into escrow and
then we verify that the intent got filled before releasing
funds. So one thing that a cross does
that I think has been criticallyimportant to us working well to
date is we don't verify each intent individually.

(49:09):
So this, the naive system would be like, OK, intent got filled.
I now need to send a message proving that the intent got
filled to release that users funds from escrow.
And that means I'm sending one message per transaction, per
bridge transaction, which you know, we're doing 50,000 plus
transactions a day. It's a lot of messages that are

(49:30):
costly. It's just a lot of stuff.
And so we've always taken the approach where it's like, well,
and you also have to send the message.
It's pair wise, right? So if I support N chains, I have
n ^2 routes and so I have to send messages in all these
directions and it's it's, it's kind of a mess.
So we've always had the approachthat we're like, actually we're

(49:51):
better off batching all of the verifications into a period in
epoch and we make it about an hour.
So we say, OK, for every hour, we're going to look at all the
fills across all the chains. And we're going to create this
data structure, we call it a bundle that says here's all the
fills that happened at all the chains.
We sum them up. If you're a solver that did like

(50:14):
10 fills on one route, we say we're going to pay you once for
back for all these fills, which also reduces gas costs.
Do all this stuff and then we take this bundle, we
optimistically verify it using UMA on main net.
And then once that bundle is is is been not challenged past the

(50:34):
challenge window, we then use the canonical message bridges to
send it to all the L twos to a contract that will release funds
if there are funds to be released to All's chance.
So it was like a long process I just walked through.
But yeah, we're basically doing batching and we're
optimistically verifying this batch and they're using the
canonical bridges to send that bundle to all the chance.

(50:55):
That makes a lot of sense. Let me just quickly kind of
interject here kind of the people who kind of verify this
on the UMA network. So the people they are in
principle the same crowd kind ofalso you go to for Poly market
statements and so on. So kind of how kind of verifying

(51:16):
a data structure and kind of saying whether who was elected
president are two very differentskill sets.
And I think kind of like not, not kind of one is much more
vanilla than the other, right. So kind of like how do you scale
up your your validators to kind of to kind of, yeah.
Well, there's two, I think thereyou're sort of skipping one step

(51:39):
here because there's there's thedisputer in the cross system.
So the disputers actually naturally are solvers in our
system too, where they're like, wait, this bundle doesn't pay me
back the money I'm owed, I'm going to dispute it, right?
So we actually have a natural set of sophisticated disputers

(52:00):
for the across system to be like, this bundle isn't right.
Once it's been disputed, then you're absolutely correct.
Then the same room of voters that are voting on, did Trump or
Harris win the election are now voting on, was bundle A or
bundle B correct, right. Or rather they're voting on, was
bundle A correct or did it miss something?

(52:22):
But they now have period, like time where it's like somebody
can go and be like, if you run this code, which you can go and
do yourself and you should go and do yourself, you can see
that this bundle was incorrect for this reason.
And so then the voters are kind of just able to capture that
part effectively. OK.
Does that make sense? Yeah, that makes sense.

(52:43):
Maybe let's talk about kind of like the wider bridging space,
OK. So kind of we see kind of.
Can I go back? Because we didn't talk about the
ZK bit in Across yet and I want to make sure we, we, we get
that. So first step, if you go back to
our design where we're doing this batching optimistically
verifying this bundle. And then because we actually had
this belief where we didn't wantto add in additional third party

(53:05):
trust assumptions, we were usingthe canonical bridges to send
this bundle to all the chains. So a requirement in the across
system before ZK was that you had a canonical message bridge
that could connect to Aetherium L1 and there are chains that
don't have that and they're growing, right.
So what we've done with Succinctis we've created a ZK proof of

(53:31):
that bundle and then we're able to take that ZK proof and bring
it to any chain include like including chains that aren't
connected to Aetherium mainnet like Binance Smart Chain.
And we can then verify fills in like they had a canonical
message bridge going to that chain.

(53:51):
So we're able to use ZK to basically delete the need to
have a canonical message bridge between Ethereum L1 and the L2.
And this has advantages also forL twos that do have canonical
message bridges because they're different.
We actually take this engineering work and like smart
contract audits to add new L twos because their message

(54:14):
bridge might look different, whereas the ZK proof is the same
on every chain. So our new process is batch
verify, sort of create, batch, batch these intents, verify them
optimistically, create AZK proof, and then send that to all
the chains. You can't imagine that we might
be able to do more ZK stuff. Hint hint.

(54:36):
Like we might be able to do moreZK stuff that lets us like
further compress that process and get to get to more chains
faster too Cool. Yeah, I know that that
definitely makes a lot of sense.How do you see kind of the
fragmentation in the bridging space?

(54:58):
So do do you think kind of we'reconverged towards one dominant
model or do you think kind of we'll retain kind of this
baconized state? There's an incredible amount of
nuance in that question. But again, you have a nerdy
listener base, so we can we can touch on it, right?

(55:21):
Bridging is bridging is like an overloaded word that means a
bunch of things here. There are many bridges that are
mint and burn bridges for specific tokens.
Example circles USDC, they have their own mint and burn bridge
called CCTP Circle Cross Chain Transfer Protocol that lets you

(55:46):
burn USDC on one chain and mint and on another, right?
So it's a form of bridge, but it's quite different from what
we do. It's meant to be like really
secure and they take 20 minutes coming from a theory and stuff
like that because circle does not want to just mint, you know,
$10 million on some chain by mistake, right.

(56:07):
That would they would lose theirown money.
OK. And then you've got layer zero
with OF TS. So they're using OF TS to do
something similar with their ownset of security assumptions,
with their own set of validators.
You have wormhole doing NT TS, same deal using wormhole
validators. But these are not the bridges

(56:28):
that look like what we're doing.These are like allowing you to
mint and burn a specific token on different chants.
And that to me feels very fragmented.
And that's not the business it crosses in at all, nor the
business we're going to enter. And I do feel like there is
going to be fragmentation there for a long time.
There's going to be like many standard, many teams that are

(56:51):
warring for market share around minting and burning tokens here.
That's one thing on the bridgingside, when I think about the
bridging architecture, I, I think intents are the clearly
the only way that Ethereum is going to feel united and broader
crypto is going to feel united too.

(57:13):
And I do not think that means that like everybody uses a
cross. I don't think that that's right.
But I think the intent, standardintent concept is I think this
need for speed for having transact transactions take like
2 seconds or less. I think that is critical from
just a user experience in a multi chain world.

(57:33):
So we, we created a standard forintense, we co-authored a
standard with Uniswap called ERC7683 that defines a common
interface to express an intent. And we're doing this as a public
good. So that many intent protocols
can adopt the same intent standard and solvers can listen

(57:56):
to the same intent format makes it less work for solvers to
support intent systems. And in doing so, we can kind of
like push this to 2nd or less user experience everywhere where
a cross is meant to be a serviceprovider.
I hope to be the premier serviceprovider of Intense, but by no

(58:17):
means like the only one. Does that make sense?
It's a long answer. That makes sense.
Do you think bridging is something that in the future
mostly builders will have to worry about?
Do you think kind of this will be this experience will be
abstracted the way in the user experience layer?

(58:39):
Yes, although I thought that fora couple years and it's been
actually pretty slow to happen. So we have for, you know, a
cross is integrated into Uniswap, which I think is kind
of cool. It's been a big integration for
us. And I we've sold the cross or

(59:02):
we've attempted to sort of talk to a bunch of Daps that should
integrate across into their products too.
And we've had some traction and some interest.
But when we look at our volume and where it's coming from, the
majority of volume still comes from front ends or aggregators,
places where users go and they say I want to bridge and they

(59:23):
specifically are going to like the across .2 front end to
bridge from chain A to chain B. And it's been slower than I
expected for that process to getintegrated and abstracted into
Daps that builders do. And I don't actually think I

(59:44):
totally know why yet. My working theories are crypto
is still got a bunch of D Jens that actually like doing
bridging manually. They like enjoy the process and
they enjoy doing it. That's one theory.
The other theory is the infrastructure and the kind of
standards around bridges haven'tmatured enough.

(01:00:07):
That builders feel comfortable integrating it or really pushing
it is another theory. Yeah, but.
I think that that's the one thatkind of like I, I would probably
subscribe to kind of you don't want to bake something into your
system that you don't know is going to be around in six months
from now, right. So, so I think kind of as, as a

(01:00:31):
builder kind of saying, OK, look, we'll just be agnostic
here. That's often simpler.
Yeah, I think you're probably right, or I think it's a working
theory, I should say that. And they also think wallets play
an important role here. SO77-O2 and putting smart
contract wallets everywhere. I think it's huge for intense

(01:00:52):
and huge for across. And this is something that
frankly, we need to be a bit louder about.
Other people need to be a bit louder about too.
But if I have a smart contract wallet everywhere, there is a
design pattern where I could keep my money on a home chain,
like let's keep doing the A to Bexample.
So I keep my money on an arbitrum that's just my

(01:01:14):
preferred bank, like home chain bank.
But I can sign a user OP or signa message to do any arbitrary
action on chain B, even if I have 0 money there, like
absolutely 0 money there becauseI can pay for that action from
my home chain. And basically the, the kind of

(01:01:35):
the abstraction here is I'm bridging the gas money to
execute this user OP on chain B.And I'm doing that incredibly
quickly, right. And so, you know, once we have
smart contract wallets everywhere on all the chains,
this idea of, you know, I'm not really sending funds to the

(01:01:56):
destination chain. I'm sending a message I want to
execute and I'm like just in time delivering the money to pay
for that message. I mean, I think that's a very
compelling feature of how you like unify all the chains and
make everything feel like one network again.
So that's, that's the UX that I'm most excited about.

(01:02:18):
And I, I do think that's mainly going to be driven from the
wallets. But then there's like
fragmentation and sort of still a bunch.
There's a bunch of people that are heard to to figure that one
out too. Yeah.
So I mean the the entire kind oflike smart, smart wallets on all
chains kind of thing there. There's a bunch of underlying

(01:02:40):
problems that I think are not generally appreciated enough.
So kind of for instance, I mean,obviously kind of like now with
create two kind of where you cankind of create on the same
address. But then what happens if you
kind of lose one of the EO as onone of the chains or kind of
like you kind of you don't have all the EO as on all of the

(01:03:01):
chains or kind of like there, there's a lot of kind of like
what, what, what happens with recovery?
And kind of like it's, it's a little bit of, of, of a messy
situation. And I think, I mean, I've also
always been in camp kind of we need smart wallets just because
kind of like it's, it's clearly the way better user experience,
But they are still there still are kind of a bunch of unsolved

(01:03:25):
user problems kind of that come with it.
Yeah. Well, like you have experience
here, you know this right. This is like the being in
industry and trying to not the theory but the practical like
implementations here too. And I think like this is where
what, what worries me is just ittakes longer because we've got

(01:03:46):
to like figure these problems out, takes longer to get to the
solution I want or I want to seein the world.
It doesn't change the fact that we're, I still think we're
heading in the right path. Like you said, we need smart
contract wallets everywhere. And then we need infrastructure.
And I really think of like what we're doing from intent
bridging. It's, it's a layer of

(01:04:07):
abstraction. Like the intent is just this
layer of abstraction on top of some pretty complicated piping
about how these genes might actually be connected.
And so the solvers might be using finance to rebalance or
whatever. It doesn't matter.
There's just all this other piping under the surface that
users shouldn't have to see because they're operating on

(01:04:27):
this like thin intent layer of abstraction.
And that I have a lot of conviction that that's like a
necessary piece. I just want to get out there as
fast as we can and then make theuser experience be as abstracted
as possible. But yeah, it might be a little
bit for me to do that. How do you see the interplay
between bridges, roll ups and shared sequencing?

(01:04:52):
So kind of could could across one day kind of integrate with
shared sequences. It's a really, a really good
question and really nuanced. I, I, there are so many

(01:05:13):
innovative technologies around like pieces of interoperability
and, you know, to take A, to throw something else there that
you didn't mention, like think ZK proof aggregation, kind of
like some of what the like the egg layer stuff is doing to.
There are ways that you're goingto, you're going to have really

(01:05:35):
interesting ways to send messages between chains to and,
and send funds shared sequencingtoo.
There's like, OK, so fun ways that a couple chains or some set
of chains could be, could do somewhat synchronous things
between them. I think it's it's great when I

(01:05:56):
look at this, there is no, there's no, no one technique
that's going to touch everything.
It's like there's going to be these like pockets of
interoperability. And you see this with like, OK,
so super chain might have some interoperability here and there
might be, you know, some shared sequences over here and some egg
layer proof aggregation over here.

(01:06:16):
And then these chains are connected by Binance over here.
And you just have these like this Venn diagram that does not
have everything under 1 circle. And the way I look at it is
intense are that one circle kindof layer of abstraction where we
basically put the solver in charge of figuring it out.

(01:06:38):
And they can use any of these underlying techniques to do it
faster and cheaper, which lets them deliver the intent product
to users at a better price. So that's kind of how I see the
interplay between all these things.
Does that make any sense? Yeah, makes a lot of sense.
I think there's still a lot of things to kind of like be hashed

(01:06:59):
out, but I think kind of this isalso kind of just the state of
the of of the technology, right.I kind of have one final thing
kind of like I'd like to touch upon because we haven't actually
talked about it at all. So Uma and across kind of they
are super cool projects and kindof what I always find

(01:07:20):
fascinating is how where kind ofyour governance systems work.
So kind of kind of if you look at the Daos kind of they are
pretty they are pretty alive, right?
So kind of if you look at at kind of your Daos and kind of

(01:07:41):
the the common DAO, what do you think you guys are doing right?
Wow. You know, it's funny because we
just got some weird FUD on the Internet about attacking our
governance. And it was wild because I
generally agree. I think we've actually done a
pretty good job on this. We've been around for a while.

(01:08:07):
We actually have a lot of token holders that are not investors
that hold like reasonable chunksof tokens too, I think.
And again, I don't actually track token addresses or know
who people are. But by being around for a while,
we have former employees that like us, are happy with us and

(01:08:27):
have chunks of tokens and actually participate in
governance, which I think is cool.
Yeah, for dictating. It's an interesting question.
I mean, I appreciate it. But I think we try to have, we
try to, I try to direct kind of our foundation that's doing the
work risk labs to be relatively opinionated about what we think

(01:08:51):
is good or bad in a way that minimizes Dow infighting.
It's kind of what we try to do and we try to make proposals or
suggestions that we think make alot of sense and have to be well
reasoned. And then we like, yeah, have a

(01:09:13):
bit of an opinion. So I, I think in the spectrum of
like we are by no means operating like a centralized
company, like centralized Delaware C Corp, but we're also
not trying to be like, hey, community, you guys figure it
all out too. We're trying to do something in

(01:09:35):
the middle. We were basically like, here's
what we think should happen fromthe Risk Labs Foundation
perspective. And we are looking for community
sign off on it, which frankly islike it, it is like how a
Delaware C Corp shareholders interact.
It's like a management team makes a shareholder proposal and

(01:09:57):
we ask shareholders to vote on it, right.
So I think that's the the kind of analogy we've been going for.
For people who kind of want to become involved with either UMA
or Cross or kind of who want to build on top of you guys, where
do we send them? So you can follow me on Twitter

(01:10:17):
at Hal 2001. It's my initials Hal 2001, which
is also from 2001 a space Odyssey.
But you can follow me at Hal 2001 on on X or Twitter.
And then the two projects, it's a cross protocol and UMA
protocol on on X or Twitter. Follow us there.

(01:10:38):
We we're hiring and building actually a lot of fun stuff.
Sorry, small plug. And you know, we're trying to
engage in like there's a bunch, there's a bunch of really
interesting stuff going on both on like the polymarket side, how
do we actually scale this Oracle?
How do we use AI in this? And then on the bridging side,

(01:10:59):
how do we like make Ethereum andmake Web 3 just feel like one
network again? So I'm pretty pumped about our
near term objectives too. Super cool, thank you for being
on. Thank you so much for having me
really fun.

All Episodes

UMA & Across: Optimistic Oracles & Intent-Based Bridges for Unifying Ethereum - Hart Lambur

Episode Transcript

Popular Podcasts

Dateline NBC

Are You A Charlotte?

Stuff You Should Know

.css-15opob5{left:0;position:absolute;top:0.8rem;} All Episodes

.css-14f5ked{margin:0;word-break:break-word;display:-webkit-box;-webkit-box-orient:vertical;box-orient:vertical;-webkit-line-clamp:2;overflow:hidden;}UMA & Across: Optimistic Oracles & Intent-Based Bridges for Unifying Ethereum - Hart Lambur