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 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 challenge period could say, I disagree.
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 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 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 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 white label note, restake your assets on Eigenia or Symbiotic, or use the SDK for multi chain staking in your app. Learn more at Chorus .1 and start staking today. 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, 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 Nosis Chain. 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, or working on autonomous agents, Nosis Chain gives you a solid, neutral foundation to build on.
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. 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 building on 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 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. 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 me and worked beside me for four years 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 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 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.
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 and when did you kind of decide to 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 this or the way I like to think about it is our initial thinking was we should write financial 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 be part 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 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 the data about like what the output outcome of this financial contract should be. Concrete example, like you and I do 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 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, there's synthetic make assets is what we did, synthetic assets that track some other underlying object 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 need to build like part parts to kind 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 from the UMA ecosystem and across is a bridge kind of like which which is already kind of clear 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 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, synthetic assets.
That might actually be changing right now. We'll see. But but we're like, we have this 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 faster than 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 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 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. 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 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 like only 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 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 game theoretic concepts and crypto economic concepts. But the core idea is pretty simple. We say, hey, anyone on anyone on the 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 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 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 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 escalation mechanism 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 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 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 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 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. 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. 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 are situations where you are incentivized to actually vote against your beliefs just 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
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.
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?
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? 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 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 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 philosophical and theoretical thoughts here too. Like again, the lab leak example is 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, 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 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 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. 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 in the in the in the negated form usable kind of as an input for smart contracts or is it is it tainted and we have to have a new new vote? This is this is up to this is up to the integrator that wants to like use this Oracle like they could go either way. I prefer the design because this voting process also takes a while, right? So one of the things that we've seen with Polymarket, for example, is somebody will 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,
right? So. That will get disputed and it'll go 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 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 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 say no one says yes, it still get it goes kind of like unchallenged somehow because people missed it. And despite the fact that almost all 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 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 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 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 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 what you 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 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 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't speak for them.
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 examples and 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 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 production markets 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
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 kind of like costs you kind of a proportion 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 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 think are 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. And you know, this is where I will give like Polymark deserves a lot of credit for figuring out how 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 and have it like mostly work. Yeah, yeah, I, I agree. What's your take on fine print 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 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, but clearly 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 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 just strictly enforce definitions?
Well, you, you can't strictly enforce definitions because the English language or any language is 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 opinion and I don't vote or participate
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 that just didn't capture the spirit of it at all.
So yeah, the thing that is super interesting about prediction markets, if we go back to call them financial contracts, they're financial contracts, but they're binary. One side wins 100%, the other side loses everything. 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 try to 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 an incentive to scream. The system is broken. Scam manipulation, like all this other 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 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 here too. But I think we really try to use the 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 days, Auger had a lot of invalid market 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. 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. 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 more, and there's like a very cool project we're working on that's not far away that I think can 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. 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 processing between 250 and 500 proposals a day like market resolutions a day, which is up a lot from six months ago. Give us an idea of kind of who uses Uma's Arca, Yeah. So the biggest user by number of proposals by far is Polymarket.
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 recreate, but it would be hard to do on chain. Anyone can do it off chain easily though. And Across uses Zuma to validate whether 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 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 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. 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 this is too early or I shouldn't do 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 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 to dispute this if somebody does try to sneak a battle come through?
However, this is where all of like the Super intelligences 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 lot of things, and I think that that actually strengthens many of the optimistic 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 of like as a consumer of Uma, the 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
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 happy to have other users of UMA and 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 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 rushed out because we actually needed, we needed a token to gather some LP funds to help make the bridge usable. Like we needed token emissions to incentivize people to deposit into our protocol.
And we actually came, put this out just a little bit before people sort of started doing the points thing, like the points program thing. And it's funny because I think first of all, I wish we invented that 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 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 early on too. 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 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. 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 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 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 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 enough to price the reorg risk or understand the risks they're taking, and we could use them to front 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 starts for the third party solver to fill them on chain B, Third party solver fills them on chain B very quickly. And then user goes on with their day, they're happy, and then the protocol says verifies that fill happened before releasing the funds back to the solver. Yeah.
I mean, it's a slightly different design than many optimistic bridges where kind of you say, OK, look, you kind of you, you kind of you bridge optimistically and there's kind of there's a message sent across that 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 on the destination chain for a couple of basis points until kind of the optimistic time the 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 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's nothing 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. But they're very good at pricing this 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 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.
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 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 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 type of 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 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 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? 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 this pricing mechanism? 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.
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 users that use like our API or use our front end, we will suggest a fee of what the the user should submit. And then all the solvers are purely competing to win that fee on 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 marginal cost that like purely competitive price of what it would take to fill on the destination chain because we are trying 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.
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 I think there's very cool ways that we can do both that are are still 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, the fee is a matter of gas costs on 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. 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. 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 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. 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 like kind of the the cost kind of balance. So you kind of recently switched to 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 it really is magic.
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 layer of who's the solver that's actually doing the work to fill the intent. And there's the settlement layer where 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 critically important to us working well to date is we don't verify each intent individually. 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 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 approach that we're like, actually we're 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 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 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.
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 of also you go to for Poly market statements and so on. So kind of how kind of verifying a data structure and kind of saying whether who was elected president are two very different skill 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 there you're sort of skipping one step here because there's there's the disputer 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 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?
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. 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 want to add in additional third party trust assumptions, we were using the 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 Succinct is we've created a ZK proof of 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. 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 for L 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 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. Like we might be able to do more ZK 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? So do do you think kind of we're converged 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? 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 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. That would they would lose their own money. OK. And then you've got layer zero with OF TS. So they're using OF TS to do something similar with their own set 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 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 warring for market share around minting and burning tokens here. That's one thing on the bridging side, 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. 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, standard intent 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. So we, we created a standard for intense, we co-authored a standard with Uniswap called ERC 7683 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 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 service provider. I hope to be the premier service provider of Intense, but by no 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? Yes, although I thought that for a 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 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 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 get integrated and abstracted into Daps that builders do. And I don't actually think I
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't matured enough. That builders feel comfortable integrating it or really pushing it is another theory. Yeah, but.
I think that that's the one that kind 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 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 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 B example.
So I keep my money on an arbitrum that's just my preferred bank, like home chain bank. But I can sign a user OP or sign a message to do any arbitrary action on chain B, even if I have 0 money there, like absolutely 0 money there because I can pay for that action from my home chain. And basically the, the kind of 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 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.
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 of like smart, smart wallets on all chains kind of thing there. There's a bunch of underlying 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 can kind of create on the same address. But then what happens if you kind of lose one of the EO as on one of the chains or kind of like you kind of you don't have all the EO as on all of the 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 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 it takes longer because we've got to like figure these problems out, takes longer to get to the solution I want or I want to see in 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 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 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 the user 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? 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 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 going to, you're going to have really interesting ways to send messages between chains to and, and send funds shared sequencing too.
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 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. 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 kind of layer of abstraction where we basically put the solver in charge of figuring it out. 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 out, but I think kind of this is also 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 kind of what I always find fascinating is how where kind of your 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 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.
We actually have a lot of token holders that are not investors that hold like reasonable chunks of 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 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 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 a lot of sense and have to be well reasoned. And then we like, yeah, have a
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 the middle. We were basically like, here's what we think should happen from the Risk Labs Foundation
perspective. And we are looking for community sign off on it, which frankly is like it, it is like how a Delaware C Corp shareholders interact. It's like a management team makes a shareholder proposal and 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 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. 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, how do we like make Ethereum and make 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.