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

Transcript

Our initial thinking was we should write financial contracts on a blockchain. It makes them globally accessible whereas financial contracts in tradi 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 out outcome of this financial contract should be. We were inspired by things like Vitalik's Sheloncoin blog post from 2014 and various like game theoretic concepts and cryptoeconomic 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. What Across did is we're like our whole MMO is we want bridging to be a two-c or less experience. We want it to be fast and cheap, but we think like the speed is critically important. >> Welcome to Epicenter, the show which talks about the technologies, projects, and people driving decentralization and the blockchain revolution. I'm Fedrica Ans and today I'm speaking with Hart Lamper who is the co-founder of UMA and across protocol which are two interrelated projects um in the wider Ethereum space.

So UMA is a decentralized optimistic oracle and across is a bridge um that in some flavors uses UMA under the hood but we'll get it to that in in just a second. Before I talk with heart let me tell you about our sponsors this week. If you're looking to stake your crypto with confidence, look no further than Chorus One. More than 150,000 delegators, including institutions like BitGo, Panta Capital, and Ledger, trust Chorus One with their assets. They support over 50 blockchains and are leaders in governance or networks like Cosmos, ensuring your stake is responsibly managed. Thanks to their advanced ME 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 iggon layer 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 Nosis, 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 Ethereum's very first projects. And today, it's grown into 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 lowcost, highly decentralized layer 1 that's compatible with Ethereum and secured by over 300,000 validators. So whether you're building a DAP, experimenting with DeFi, or working on

autonomous agents, Nosis Chain gives you a solid neutral foundation to build on. But Nosis is more than just infrastructure. It's also tools that people can actually use like circles for example lets anyone issue their own digital currency through networks of trust not banks. And then there's Metry. 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 Nosis Pay. All this is governed by Nosis DAO 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 one GNO and some basic hardware. To learn more and start building on the open internet, head to

nosis.io. Nosis, 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. Um, so maybe before we kind of dive into kind of like all the awesome stuff that you're building, tell us about um who you are and how you got here. >> Uh, 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 was on here. Um, TLDDR, I studied computer science. Uh I

then worked in financial services uh at Goldman Sachs as a bond trader like US Treasury bonds in the financial crisis. Uh Allison uh was two years junior to me and worked beside me for four years there something like that. Um and we worked very closely together and that's how we got to know each other in the first place. Um trading bonds during the financial crisis US treasuries during the financial crisis was super interesting. It's not my background but I learned a lot about finance. I learned about about market structure, learned a lot about actually incentive structures and what incentivizes people. Come back to that. Um, I left to do a fintech business that went 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 uh this decentralized finance idea uh before DeFi was a term. Um, if we go back to 2018, people hadn't really thought about that as a concept yet. And Frederri K, you'd remember this from like Nosis 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 we build um on smart contract platforms and on Ethereum? >> Yeah, absolutely. So, kind of the thing that you guys started back then was called uh universal market access or UMA for short. Um, and you actually started with um um synthetic assets. Um, ho how I mean you came from a trading

background, so kind of I guess it kind of like it it checks out, but um 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 uh 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 um our initial thinking was we should write financial contracts on a blockchain. That makes all the sense in the world. Uh it als it makes them globally accessible whereas financial contracts in tradi 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. Uh blockchain uh actually can do that pretty well with economic incentives. Okay, so we like this idea of financial contracts. You could call them derivatives. Divatives 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 out outcome of this financial contract should be. Um, 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, etc. 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 okay it's super early days like 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. Um let's make tokens that look like financial contracts. They're uh derivative contracts. They're synthetic assets is what we did. um synthetic assets that track some other uh underlying object and we can use our oracle to power that.

So that'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 uh parts to kind of power this and then kind of like the the parts that power this kind of become your main thing kind of later. And this kind of happened again, right? So kind of like you you guys have since launched across which also kind of came out from the UMA ecosystem. Um and I mean across is a bridge kind of like which which is already kind of clear from the name but what prompted this?

>> So um honestly we wanted more use cases for the um Oracle. Um and we did basically it was an internal hackathon. >> Again there might be like nois parallels here too because you guys also came to spawn up bunch of ideas along the way. Um actually we always kind of looked at you guys for for inspiration that way but um we wanted more use cases for this UMA oracle and we're like okay synthetic assets they weren't really taking off. This was you know four years ago 3 four years ago people wanted to trade um crypto assets not you know synthetic assets that might actually be changing right now. We'll see. But um uh but we're like we have this really interesting oracle that can give you uh

give you data on anything. It it can even give you data on what's happening on an L2 faster than the 7-day bridge um is going to let you get data from that L2. And we actually use this as an internal hackathon to build uh a fast exit bridge uh from optimism. Um it went one direction only. it went uh it only let you get off optimism. This was the first internal hackathon and then we're like ah you know there's something here. Um and then we thought about it a lot harder. uh came up with this these early like intentbased designs which I'm sure we'll get into and realized that we had a really compelling product um in this super fast

intentbased bridge um to connect mostly EVM chains um and then launched across uh 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 um Uma you already alluded to this. So kind of it's an optimistic oracle. So what does this mean and how does it differ from um more traditional oracles 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 uh we're going to have a series of nodes um or some some set of nodes write price

data to a blockchain. Um, and so it's it's very constrained in that it will like only write the price data that those nodes know to write. Um, works great for Bitcoin prices, Ethereum prices, that kind of stuff. Um, uh, okay, cool. But we were trying to solve the generalized problem of we want to get any bit of data on any bit of verifiable data onto a blockchain. Um, and uh, we're like, okay, well, we need a different system to do this. Um, we were inspired by things like Vitalik's Shellingcoin blog post from 2014 and various like game theoretic concepts and cryptoeconomic concepts. But the core idea is pretty simple. We say, hey,

anyone um 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. Um and then there's a challenge period and anyone anyone else on the blockchain during that challenge period could say I disagree right uh first step the happy path the optimistic path is nobody disagrees um and so then that that that proposal gets taken as true. Um, and there's there's bonds and there's incentives here to both propose correctly um, and to dispute correctly.

And there's penalties if you propose incorrectly or dispute incorrectly, too. Um, 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. Um, that's that's the core concept. walk me through what happens if um I uh post an untrue statement and someone calls me out on it. Um h how how I 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 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, um, Feder Rica, you propose that, uh, Harris won the election. We'll use that example. Um, and you have to post a bond to do that. The bond can be a a parameter of the protocol or the system, but you post a bond to say do that. Let's say it's $1,000. Um, and then I can be like, actually, I disagree with you. I think that's untrue. I post a matching bond of $1,000 to dispute you and say this is untrue. Um, okay. Okay. So, first thing that UMA does is now that there's a dispute, uh, that data won't get used in the underlying contract. Um, 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, um, this is mostly true. So, if it was Poly Market right now, Polymer would be like, okay, we we're not going to use your proposal that Harris won. We're going to wait for another proposal uh later on. Um, but we still need to resolve between the two of us who was right to figure out where we get those bonds. Do the $2,000 worth of bonds go to you or do they go to me? Um, and so then this is where we lean into like Vitalik's shellingcoin uh blog post ideas where and this is also a lot of concepts from Augur and Nosis and early production market type stuff too. But we

go and we say to all our token holders uh they they go through a two-step uh voting process where they vote in secret uh what they believe is true whether your proposal or my dispute was correct. Um and uh they they they vote in secret and then they reveal all at once. Um and uh the game theory and economics of this design are such that you're incentivized to vote your own beliefs, your own truth. um and the majority will get rewarded with uh with a reward at the expense of the maj of the minority that voted against the majority outcome. Um and so we use this shelling point concept to resolve who out of the two of us was correct by having this

distributed decentralized uh voter base here. >> Okay. 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 um I give you I give you an example. So say the COVID lab hypothesis right. So kind of like um early on kind of like there was there was already a very vocal kind of minority who kind of who were who was advocating for this um and kind of as time went on um it turned out that kind of like they weren't crazy and

maybe maybe 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 co 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. Um they were involved in covering it up or or however they kind of come to know this, they would still have been um incentivized 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 um like I think if you ran a long-term prediction market over like the COVID lab leak theory, um 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 um uh in in theory um a voter uh you can't trust what other voters say they're going to vote. They actually have an incentive to frankly lie to you. Um 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 uh 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, "Okay, 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 uh 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 that's 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 um uh 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're penalized uh you're penalized less, right? So the penalties here are also um they're parameters of the system. There's probably a lot more modeling we could do to figure out how to optimally set them. Um 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. Um like I we want to design the penalties so there's a strong incentive to do your own research and vote correctly. Um and we want to design the penalties so there's a strong incentive to have people uh continue to vote and show up um all the time. Uh 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. Okay, that's fair. So, let's go back to the to the Harris example. So, I posted the Harris won the the presidential election um statement. You contested this and kind of there was a vote that kind of confirmed that you are right. Um, is this statement now kind of in the in the um in the negated f form usable kind of as an input um for smart contracts or is it is it tainted and we have to um 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 Poly Market, for example, um is somebody will propose an answer um they often they propose the answer too early. They're like uh like a sports game is a good example. They propose that someone's going to win the sports game, but they propose like five 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 okay to propose five minutes early. Like what?

It could have changed around, right? So that will get disputed and it'll go through this voting process. Um but we don't want that that polyarket 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 um because it's after the game completed and it has the right answer. So that's like an implementation decision of like how Poly Market would use the oracle in this example. Um I prefer it. I prefer the idea of uh you only take as truth undisputed markets that are not tainted and the um the dispute process sorry the voting process is really to resolve disputes uh and like where the bonds go. I prefer that

because the economic security behind that is like much much deeper um in many ways. Um but it's a parameter it's it's up to the integration decisions of the protocol. >> Okay. But in in that um in that design um 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 goes kind of like unchallenged somehow because people missed it. And despite the fact that almost all of them kind of point one way, you you could you would you don't actually have to wait for kind of like any dispute to be resolved. um you can already kind of use the one yes

statement to resolve, right? >> Uh sorry, walk me through this. How do you where did the 500? >> There's there's so kind of say there's um 500 people kind of like post an answer to post a statement um uh who who won the election. So say 500 kind of say Harris and kind of like 499 of those get contested and one just kind of gets missed 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 Poly Market's implementation at least um you couldn't have they wouldn't let you have 500 proposals for the same market um 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. Okay. And then other people there's like stuff that that we do to to kind of um uh make sure 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 polymer markets scaling and other use cases are scaling. Um 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. Um which I find super compelling and interesting. Um but yes your your example is a fair one and we have to put constraints around this this too.

>> C can I grief um kind of the market creators or the people who have market uh money on the market um by creating uh two conflicting or two wrong statements and kind of like just um making sure that kind of they incur the opportunity cost of not being able to kind of get their capital out of the market. >> Poly market does not allow permissionless market creation at right now. um uh may I I can't speak for them and I don't want to speak for them but like one reason might be this problem right um and if you go back and I think ELO you know you have experience with this but we look at augur 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 um I think that's a hard problem to solve um again I think you could uh going forward if if I were to design like a permission less prediction market kind of system here. Um 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. Um but I think these are these are all the problems that production markets like have to solve to keep scaling um and growing. So I think you you know you have a lot of experience and personal interest in this I think and uh uh yeah it's um uh it's a good question but that's why Polymarket doesn't let anyone do it right now.

>> You could also kind of um uh tie the um amount of the bond you have to p put to the amount of money in the market. So that 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 that I think 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 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 heruristics 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 uh to keep things working effectively. And um you know this is where I will give like poly market deserves a lot of credit for figuring out how to actually grow and scale these markets um and even since the election they have figured out how to have many many more markets than they did 6 months ago um and have it like mostly work.

>> Yeah. Yeah. I I agree. What's your take on um fine print driven outcomes on prediction market? So for instance kind of um on a kind of invalid outcome was kind of a huge problem. Um, and uh, one that kind of comes to mind where I actually think kind of like Uma worked really well as an oracle was kind of um, do you remember that submarine that kind of sank um, and uh, kind of there was a market on Poly Market with a submarine be found um, and clearly it wasn't found because kind of like it imploded, right?

Um, but kind of somehow kind of but clearly that was not the intent behind the market. Um so and Uma actually resolved it to yes it was found. Um and kind of I I remember there was kind of some uh upheavo 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. Um but it's really difficult. So what what's um what's your take on this kind of should or 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? Um Frederick G like it's so funny you brought up that example because I I agree with you personally and like you know um in the moment I don't have any opinion and I don't vote or participate in these markets myself at all. Um, but there was a bunch of people that were trying to argue that um, you know, they found pieces of the submarine. Um, but they didn't find uh, a big enough piece of the capsule to fully confirm it was it imploded, right? Um, but like it ob it was like a very nuanced reading of the rules that just didn't capture the spirit of it at all. So, um, yeah, the

thing that is super interesting about prediction markets, um, if we go back to calling them financial contracts, they're financial contracts, um, but they're binary. One side wins 100%, the other side loses everything. Um, 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 uh 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 uh the system is broken. uh 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 um 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 poly market has a process now of issuing clarifications around markets um 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 um but I think we really try to use the shelling 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 um to resolve these markets Um 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 Augur days, um Augur had a lot of invalid uh market outcomes. So it just said this market isn't clear enough. We're just going to not respond. Um and Uma and Poly Market generally don't do that. Um we I actually don't know if you ever terrible user experience, right? So kind of uh 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 you're like, you kind of like can't can't answer it. Right. That's not good. Um and so uh but then that that forces the Oracle system to resolve slightly ambiguous outcomes too. >> Yeah. C can you give us an an idea of um how often um disputes happen kind of in absolute and relative terms?

>> Uh yeah, the dispute rate is less than 1% of all proposals. Um we're actually putting a lot of effort into getting it down uh more. Um, and there's like a a very cool project we're working on that's not far away that I think can actually lower it by uh an order of magnitude, too. Um, 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 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 uh% of all proposals are like legitimately disputed that aren't like too early, something like that. Um and uh the the system is currently processing between 250 and 500 uh proposals a day, like market resolutions a day, which is up a lot from six months ago. um >> give us an idea of kind of who uses Uma's Oracle um today. >> Yeah, so um the biggest user uh by number of proposals by far is uh Poly Market. Um they just they're yeah they've kind of achieved um escape velocity in the prediction market space

here. Um Across we'll talk about that maybe transition soon. across uses it um also to validate this like complex data structure. So it's a very different use case. We're basically being like here is this complex data structure that anybody can recreate. Uh but it would be hard to do onchain. Anyone can do it offchain easily though um and uh across uses um to validate whether that data structure was created correctly or not. Um and then we have other like interesting use cases that are experimenting uh like story protocol. They're kind of doing IP uh IP stuff. Um and uh they use the system to resolve some IP disputes. Um

that's just getting going. Um and then there's a like a long tale of smaller prediction market adjacent use cases too. >> Super interesting. Maybe before we kind of transition over to a cross um what what um 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. Um, they also work well where um, uh, 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 if you say this is too early or I shouldn't do this yet and you wait till there's like enough uh polling clarity, it's pretty obvious, right, what the outcome is. Um so in those use cases, I think these optimistic systems work really really well. Um where things get scary, right, uh it would be like okay, 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 uh uh question about like wait is there anybody around to dispute this if somebody does try to sneak a bad outcome through however this is where um all of like the super intelligences that people are working on become extremely useful um and you think about what an LLM can do um I don't think it completely replaces humans yet. Um, but uh, 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 uh, verification

assumptions in an extremely useful way. >> Yeah, I think that's that's a that's a fantastic answer. Um so you guys you already talked about this briefly in the beginning. So you guys um actually started a bridge kind of initially kind of like as uh um a consumer of um the Oracle. Um how may maybe kind of like the the uh the housekeeping first. How did this work in terms of ownership structures? So kind of these are two token projects. So kind of like how ho how how are the tokens related and kind of like how how did your um first set of token holders feel about kind of you guys working on a

second token project? I mean I I'm very much asking kind of not for a friend so kind of we've done this before too. So um >> um yeah we looked at you guys for some of this stuff a little bit too. Um and it was it was interesting. So that's so the way we looked at it is um UMA users were uh like are happy to have other users of UMA um at least at the time when we did this. It's like okay that makes sense. Um and then we made an attempt to launch the across token in a very fair way. Um, 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. Um, we we in in some ways I feel like the across token was rushed out because we actually needed uh we needed a token to gather uh some LP funds to help make the bridge usable. like we needed token emissions to incentivize people to deposit um 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. Um but if we had the points idea, we may have delayed the token um

much longer and used points to help incentivize some of the behavior we needed. Anyways, um neither here nor there. We did try to put the token out in a very fair way. Um we tried to have a fairly broad airdrop and uh the like the kind of UMA team actually had pretty little ownership in the across token uh at least early on too. Um and so nobody really had a problem with that. That's the way I'd answer that. >> Yeah. Um it's just kind of like we're building cool stuff in the space. It's related. It's good for both projects, good for both teams. That's good.

>> Cool. Um, so maybe let's talk about how a cross used to work. So a cross used to use, you know, a purely optimistic model. Um, let's talk about this first and then kind of like how you've recently kind of upgraded it um in the ZK RAM. >> Yeah. So, you know, your listener base is pretty nerdy. Um, so which I like. >> We'll take that as a compliment. >> It a massive compliment. um you know they're not the not the crypto curious folk that like are are we can go deep on this stuff. So um what does a cross do? Let's actually start there if that's okay. So a cross is an intentbased bridge. Um the way I I explain this and this is this is the

basic explanation but I want from blockchain A to blockchain B. We'll make it arbitum to base. Um how can I do that? Uh the naive way is I deposit something uh on arbitum. I send a message to Bass uh and then I release funds on Bass uh to the user and that's all well and good. Um that's how I I think a lot of like first generation bridges work. Um, and the problem with that is I need to wait for finality or high degree of finality on blockchain A before I send that message because if that message is wrong, I'm going to like release funds from a pool or something or mint uh tokens that aren't backed um 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 Across did is we're like our whole MMO is we want bridging to be a two second or less experience. We want it to be fast and cheap, but we think like the speed is critically important. So we're like, okay, 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 uh a third actor uh a solver or a relayer um same term um 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 pack they get paid back later after we verify the fill habit. So this is the intentbased model where a user effectively deposits on chain A. They deposit into escrow. A race starts for a third party solver to fill them on chain B. Third party solver fills them on chain B very quickly. Um and then user goes on with their day. They're happy and then the protocol says verifies that that fill happened before releasing the funds back to the solver.

>> Yeah. Yeah, I mean it's a slightly different design than many optimistic bridges where kind of you say, okay, look, you kind of you you kind of you bridge optimistically and there's kind of there's a message sent across that bridge. Um and then kind of on the other side kind of like you kind of you you uh someone someone kind of frs 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 um 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 in maybe

in 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 then the user goes and they have the money and they can do whatever they want and there's no chance of like a roll back. They just they have the funds, right? Um so it's very clear like there's nothing weird going on there. Um, and the silver 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 um uh all over the place. And so it really does allow us to have two second bridge experiences between all the major

L2s um with like very pretty low fees. Very low fees. >> Can anyone be a solver? So kind of like say for instance I I had um uh dirty funds that kind of like I wanted to distribute amongst kind of like uh innocent people kind of say from some sort of hack. Um 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 funds that they initially deposited? >> Man, you're asking like the hard questions here. Um solving is permissionless um with like asterisks and caveats. Um uh we have not had any rogue or like uh any dirty solvers participate in our network. Um and we do

have ways to prevent them from participating in our network um while still maintaining the permissionless ethos. I don't know that I actually want to share all the ways that we have to pre prevent them um for for reasons. Um but um it's it's a very good question that um we've actually gone pretty deep on. Um it it's there's also not a it's not a very good mechanism to wash funds either. Like it's all pretty uh you have to compete against our other solvers that are very competitive too and win.

So um it's it would actually require a lot a lot a lot of expertise to do this at any type of scale too. Um but >> so does all laundering kind of like laundering is is an incredibly labor intensive business right kind of like this is why Lazarus has like 20,000 people doing this. Um >> do 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 um >> Yeah. >> Yeah. Yeah. Okay. Well, um, 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. Um, and we haven't seen any evidence of this to date too. >> Okay. How does the pricing work? So, kind of like I'm I'm uh I mean, I kind of there's lots of things that kind of I have to factor in. So kind of like um 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 uh all of these things. So kind of I assume kind of every solver kind of does this kind of like on on their end. Uh but do you have any any idea of kind of like what goes into this pricing mechanism?

>> Yeah. uh I have a lot um and it's super nerdy and super fun. Um but you can actually step back and be like okay so filling this intent again go back to our example from A to B from arbitum to base filling this intent we're actually kind of uh competing on two dimensions competing on price and competing on speed who can do it fastest um and what we've chosen to do to date is actually just compete on speed so uh 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 um of what the the user should submit um and then all the

solvers are purely competing to win that fee on the destination chain competing based on speed. Um and we've done this because we really tried to sell the fast user experience. Um and so we definitely in in many ways we char well definitionally we charge too much. we charge more than the marginal cost, the like purely competitive price of what it would take to fill on the destination chain. Um because we are trying to have all the solvers compete on speed and we've gotten our own heruristics to to kind of uh set that price in a way that we think is going to lead to good competition on the fill. Um 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 uh not quite ready to talk about but um I think there's very cool ways that we can do both um uh that are are still have a good UX here too um which I'm excited about. Uh 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 uh because we batch the verification which we haven't we can talk about the UMA component here too. So our gas costs are extremely lightweight um uh both sides but there's still a gas cost that goes in pardon the fee estimate that goes into the fee estimation. The other costs would be

okay how long before we repay the solver. So they're making a loan. How what's the cost of capital? How do we um uh manage that or um the third cost would be um 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 fourth cost would be um it the fourth cost we actually get to ignore. Uh the fourth cost would be like what's the risk of a reorg on the origin chain um which would cause the solver to not get repaid that actually gets priced into the speed competition. So solvers can be like, okay, 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. Um, and so we get to think of this pretty pretty deeply. It's pretty fun. Um, but

that's that's the the nerdy answer to your nerdy question. kind of like a reverse Dutch auction, but uh yeah, and you kind of you send the the you send the bid at the at the time point where you feel like uh kind of the the cost kind of uh balance. Um so you kind of recently um switched to a ZK bridge for uh or a ZK verification mechanism for um part of the bridge experience namely to BSC. Right. >> Correct. So we've added ZK ZK magic and it really is magic. Um we've added it to part of the uh across intent verification. Let's call it the settlement system um here. So um I look

at across and all intent systems in three layers. There's like the auction layer of who's going to fill the intent. Um 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. Um so this the naive system would be like okay intent got filled. I now need to send a message proving that the intent got filled to release that user's 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 just a lot of stuff. Um, and so we've always taken the approach where it's like, well, uh, and you also have to send the message. It's pair-wise, right? So if I support n chains, I have n squared routes. And so I have to send messages in all these directions. And it's it's it's kind of a mess. Um, so we've always had the approach that we're like actually we're better off uh batching all of the verifications into a period and epoch and we make it about an hour. So we say okay 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 happen 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 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 mainet. And then once that bundle is is uh has been not challenged past the challenge window, we then use the canonical message bridges to send it to all the L2s to a contract that will release funds um if there are funds to be released to all its chains. So it was

like a long process I just walked through but uh we're basically doing batching then we're optimistically verifying this batch and then we're using the canonical bridges to send that bundle to all the chains. >> That makes a lot of sense. Let me just quickly kind of interject here kind of the people who kind of um verify this on the UMA network. So the people um um they are in principle the same crowd who kind of also you go to for poly market statements and so on. So kind of how um at 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 um your your validators to kind of uh to kind of Yeah. Well, there's two I think there you're sort of skipping one step here because there's the there's the disputer um 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 that be like this bundle isn't right. Once it's been disputed then you're absolutely correct.

Then the same UMA voters that are voting on did Trump or Harris win the election are now voting on was bundle A or bundle B correct, right? Um or rather they're voting on was bundle A correct or did it miss something? Um 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 uh effectively. Um okay does that make sense?

>> Yeah that makes sense. Maybe let's talk about kind of like the wider bridging space. Okay. So kind of um we see kind of >> can I go back because we didn't talk about the ZK bit um and 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 um we were using the canonical bridges to send this bundle to all the chains. So an requirement in the across system before ZK was that you had a canonical message bridge that could connect to Ethereum L1. Um and there are chains that don't have that and they're

growing, right? So what we've done with succinct um is we've created a zk proof of that bundle um 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 ethereum mainet like Binance Smart Chain and we can then verify Phil's in like they had a canonical message bridge going to that chain. Um, 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 um L2s that do have canonical message bridges because

they're different. We actually it takes us engineering work and like smart contract audits to add new L2s because their message bridge might look different whereas the ZK proof is the same on every chain. So our new process is batch verify uh sorry create batch batch these intents verify them optimistically create a zk proof and then send that to all the chains. You can imagine that um we might be able to do more zk stuff um hint hint like we might be able to do more zk stuff that lets us like further compress that process and get to uh get to more chains faster too. Cool.

>> Yeah. No, that that definitely makes um a lot of sense. Um how do you see kind of the fragmentation in the bridging space? So, do do you think kind of we'll converge towards one dominant model or do you think kind of we'll retain kind of this uh balconized state? >> Uh there's an incredible amount of nuance in that question. Um but again you have a nerdy listener base so we can we can touch on it right. Um bridging is got bridging is like an overloaded word that means a bunch of things here. Um there are many bridges that are uh mint and burn bridges for specific tokens. Um

example circles USDC they have their own mint and burn bridge called CCTP circle crosschain transfer protocol. um that lets you burn USDC on one chain and mint it on another, right? Um so it's a form of bridge, but it's quite different from what we do. Um it's meant to be uh like really secure and they take 20 minutes coming from Ethereum 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. Okay. And then you've got uh layer zero with OFTs.

And so they're using OFTs to do something similar um with their own set of security assumptions with their own set of uh validators. You have wormhole doing NTTS um 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 chains. And that to me feels very fragmented and uh that's not the business that crosses in at all nor the business we're going to enter. Um 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 roaring for market share around minting and burning tokens here. That's one thing on the bridging side. When I think about um the bridging architecture, I I think intents are the clearly the only way that Ethereum is going to feel united um 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, the intent concept is uh I think this need for speed for having transa transactions take like two seconds or less. I think that is critical from just a user experience um in a multi-chain world. Um so we we

created a standard for intents. We co-authored a standard with unis swap called ERC 7683 um that uh defines a common interface to express an intent. Um, and we're doing this as a public good so that many intent protocols can adopt the same intent standard. Um, and solvers can listen to the same intent format. Makes it less work for solvers to support intent systems. Um, and in doing so, we can kind of like push this 2C or less user experience everywhere. Uh, where Across is meant to be um, 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 um builders will have to worry about? Do you think kind of this will be this experience will be abstracted away in the user experience layer? >> Uh yes. Although I've thought that for a couple years and it's been actually pretty slow to happen. Um so we have for you know across is uh integrated into unis swap um which I think is kind of cool. Um it's been a big integration for us. Um

and I we've sold across or we've attempted to sort of talk to a bunch of DAPs that should integrate across into their products too. Um, 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 frontends 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 um it's been slower than I expected for that process to get integrated and abstracted into DAPs uh that builders do. And I don't actually think I totally know why yet. Um my

working theories are crypto is still got a bunch of dgens 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 um integrating it or really pushing it. Um is another theory. Yeah. But >> I think that that's the one that kind of like I I would uh 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, um, so I think kind of

as as a builder kind of saying, "Okay, look, we'll just be agnostic here." Um, that's often simpler. >> Yeah. Um, I think you're probably right or I think it's a working theory. I should say that. Um, and I also think wallets play an important role here. So 7702 and putting smart contract wallets everywhere I think is huge for intents 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 arbitrum. Um that's just my preferred um bank uh like homechain bank. But I can sign a user op or sign a message to do any arbitrary action on chain B even if I have zero money there. Like absolutely zero money there. >> Um because I can pay for that uh 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? Um, 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 future of how you like unify all the chains and make everything feel like one network again. Um, so that's that's the UX that I'm most excited about. Um, uh, 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 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. Um there there's a bunch of underlying problems that I think are not generally appreciated enough. So kind of for instance um I mean obviously kind of like now with create two kind of you can kind of uh um create on the same address but then what happens if you kind of lose one of the EOAs on one of the chains or kind of like you kind of you don't have all the EOAs on all of the chains or kind of like there there's a lot of kind of like what what happens with recovery and kind of like it's um it's a little bit of of of a messy situation and I think um 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 there 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. >> Yeah. And I think like this is where 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 um or I want to see in the world. Um 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 uh 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 Binance to rebalance or whatever. It doesn't matter. Um 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. Um, I just want to get out there as fast as we can. Um,

and then make the user experience be as abstracted as possible. Um, but yeah, it might be a little bit before we we do that. >> How do you see the interplay between um bridges um rollups 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 um the there are so many innovative technologies around um like pieces of interoperability. Um, 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 too. Um, there are ways that uh you're going to you're going to have really interesting ways to send messages between chains to and and send funds. Um, shared sequencing too. there's like okay so fun ways that a couple chains or some set of chains could be uh could do somewhat synchronous things between them um I think is is great when I look at this there is no uh there's no no one technique that's going to touch everything um it's like there's going to be these like pockets of

interoperability and you see this with like okay so super chain might have some interoperability here and there might be you know some shared sequencers 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 vin diagram that does not have everything under one circle. Um and um the way I look at it is intents are that one circle kind of layer of abstraction where we basically put the solver in charge of figuring it out. Um, and they can use any of these underlying techniques to do it faster and cheaper, which lets them deliver the intent of product to users at a better price. Um,

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 um of uh of the technology, right? Um 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 um they are super cool uh projects and kind of what I always find fascinating is um how well kind of your governance systems work. So kind of kind of if you look at the Dows kind of they are pretty um they are pretty alive right? So kind of if

you look at at kind of uh your Dows and kind of uh the the common DAO um what do you think you guys are doing right? >> Wow. You know, it's funny because uh we just got some weird FUD on the internet about attacking our governance and uh it was wild. Um because I generally agree, I think we've actually done a pretty good job on this. Um um we've been around for a while. Um we actually have a lot of token holders uh that are not investors that hold like reasonable chunks of tokens too, I think. Um, and again, I don't actually track token addresses or know who people are, but

um, by being around for a while, we have um, former employees that uh, like us are happy with us uh, and have chunks of tokens and actually participate in governance, which I think is cool. Um, yeah, for this is an interesting question. I mean, I appreciate it. But I I think we try to have uh we try to I I try to direct um kind of our foundation that's doing the work, Risk Labs, to uh be relatively opinionated about what we think is good or bad. Um uh in a way that minimizes DAO infighting is kind of what we're we try to do. Um and uh we try to make proposals or suggestions um

that we think make a lot of sense and have them be well reasoned. Um and then we like yeah have a bit of an opinion. Um so I I think in the spectrum of like we are by no means operating like a centralized company like centralized Delaware CC Corp. Um, but we're also not trying to be like, hey community, you guys figure it all out, too. Yeah. >> Um, we're trying to do something in the middle where we're 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 is like how uh a Delaware CC Corp

shareholders interact. It's like a management team makes a shareholder proposal and we ask shareholders to vote on it, right? Um, so I think that's the the kind of analogy we've been going for. >> Cool. 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, um, where do we send them? >> Um, so you can follow me on Twitter at how 2001. It's my initials. Hal, uh, 20001. uh which is also from 2001 of space odyssey but you can follow me at hell 2001 on on X or Twitter um and then the two projects it's a cross protocol and UMA protocol um on on X or Twitter

um follow us there um we uh we're hiring we're building actually a lot of fun stuff sorry small plug um and um 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 polyark market side, how do we actually scale this oracle, how do we use AI um 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 um too.

>> Super cool. Thank you for being on. >> Thank you so much for having me. Really fun.