xERC20, the Open Crosschain Token Standard | Eddie Ye - Connext

Transcript

from Eddie ye who leads Integrations over at connect so Eddie take it away all right thank you thank you just gonna wait for the slides to pop up thank you um hey everybody my name is Eddie I'm really excited to be here today to talk to you about a new ERC on the scene that I think has the potential to solve a lot of the bridging pains that we face today um we haven't shied away from bridging at all even after all the exploits and hacks and whatnot because um realistically at this point it's kind of like a basic need in the ecosystem we need a way to transfer value between all

these e different ecosystems and for them to be interoperable with each other um and that's where bridging comes in but bridging comes with its own set of challenges so let's just consider some of these challenges and where they come from um when you bridge a token you're all aware that you're not actually moving the token from chain to chain you're giving up your token on the original chain in order to get some representation of a token on another chain that representation token is a claim on the original token and um Bridges facilitate this process of like the give and take and as a token issuer or a chain that wants to bring other tokens into your

ecosystem uh the first thing you have to do is decide like how how do I bridge this token to a chain where it doesn't exist yet and there are a couple of options so you could just build your own bridge if you choose to do that um you're going to be immediately responsible for bridge security uh and that is notoriously difficult so most people most projects are not going to do that not really a viable option you if you are going to a rollup like optimism or arbitrum um there's actually already a canonical chain that exists there and it just so happens that that chain underpins the entire security of the system so it is actually the safest Bridge um that makes it very common and

reasonable for tokens to be bridged through canonical Bridges however canonical Bridges don't exist on every chain only on those rollups so if you're a token issuer and you want to go to all these hot new chains that are out there um you need to figure out something else when if you want to go to those other chains and um in evm land the canonical Bridges only connect the chain to ethereum so if you want to go from optimism to arbitrum say you would have to bridge from optimism back to ethereum suffer the 7-Day withdrawal period and then Bridge it back to or brid it to arbitrum and those two hops are relatively expensive because canonical bridges are expensive um so canonical Bridges offer

this secure option but you still have to figure out uh other alternatives for other Bridges so historically um token issuers and projects have basically chosen one of two practical cross-chain strategies the first one being just use multiple Bridges right so you can use the conical Bridges you can use a variety of third party Bridges all the bridges and in theory that should allow you to get your token to all all the chains that are out there um and usually uh the canonical Bridge version becomes what we call this like adopted version of the token because uh every time a bridge deploys a a different representation of your token

to a different chain you end up with like millions of these different tokens that all represent the same thing on the origin chain but are different tokens themselves so what you really want is you want there to be one widely adopted version that everybody uses that all your tokens all your users hold all the dex's list and all the dab support um so so you you as a project can either accept that the canonical bridg version usually becomes the adopted version because everybody in the ecosystem considers it the most safe and so that just like naturally converges usage into that canonical version um or on other chains where there is no canonical version you can try to endorse one of the bridged versions and try to get

everybody to use that version because it's more convenient uh when daps don't have to list like 14 different versions of the same typ token and everybody's kind of communicating with the same uh the same version of that token um the problem with this is that users who Bridge through other bridges that don't mint that endorsed version they have to get the version that everyone else is using at some point so that introduces liquidity pools into this conversation and liquidity pools introduce slippage so now um all other Bridges as part of this like last mile delivery step for you to to deliver your users the actual version of the token that they want to use on that chain um there has to be a swap involved between

the bridge mined version and that adopted version of the token that everyone else is using uh obviously that makes cross-chain transfers incur slippage often times and um aside from slippage being an additional cost to the user it actually breaks composability in many cases where uh you need to know exactly how many tokens you're getting on the destination chain uh it's not deterministic when you have slippage in the equation furthermore this model means that because you have pools you now have to Source like a bunch of liquidity uh to minimize on slippage and if you're a small project you're not going to shove enough uh Bridge volume through your token to actually generate enough

revenues to incentivize LPS to uh create these deep pools so you're just simply going to have a difficult time boost strapping liquidity if you're a larger project sitting on on stacks of VC Capital like yeah you can just throw money and um add incentives and that makes that problem a little easier but uh it's a terribly inefficient um way to use capital and it simply does not scale when you think of like what happens in the Thousand rollup future with a thousand different assets on a thousand different chains um even that like throwing money at it doesn't solve it so um there's one other major issue with this model and it's that when Bridges lock tokens on the original chain or the

home chain as we sometimes refer to it um this home chain is where the original token is deployed and every time Bridges lock that token uh and mint a different representation on a different chain it actually fragments that liquidity on that home chain because each Bridge contract is now custody a slice of the total uh canonical collateral on the home chain so if you want to move like a relatively large amount um of tokens back to the home home chain through one specific Bridge it's totally possible that that bridge doesn't actually have the uh uh the canonical assets the locked collateral on the home chain to unlock for you which kind of breaks that guarantee of like your tokens are are

claims that uh you can uh claim on the origin CH at any time so um this model with multiple Bridges uh it introduces slippage which is an issue and and um it it really makes things kind of complicated but it allows you to get to most all the chains out there the other option is much simpler uh it's basically just uh vendor lock in so as a project you choose one3 part one third party Bridge you designate them as like your endorsed uh bridge and the minted version of their token becomes the adopted version uh you consider that version as the only like legit one on every chain that they support and uh it makes things easier

because that bridge now um there's only one representation and that bridge owns all of them on every chain so if you need to go from L2 to L2 the bridge can just burn and mint those tokens directly um no need for no need for pools no need for liquidity and um yeah that sounds great because there's no slippage but you're also only able to go to the chains that that bridge supports U but more importantly you are now tied to your entire token is tied to the security model of that one third party bridge and that introduces systemic risk um you don't like a a classic case study is multi-chain where projects knew of the risks of a third

party validated bridge but they had no better alternatives on many other chains that they wanted to go to so they had their tokens minted through multichain uh tied themselves to the any asset system and when things fell apart their token is now unbacked and uh they don't have control over the token they don't have any recourse it's done so you're locking yourself into this proprietary token standard that um introduces the systemic risk of the bridge itself and you are not able to kind of go back from that system it's very difficult to escape from the Walled Garden of a proprietary token standard minted by a

single Bridge especially if you give it unbounded like minting privileges and unbounded flows through their Bridge so obviously this option is not too hot either um so just as a summary we have bridges that meant representation tokens on other chains they're actually free to do that like it's a permissionless model any Bridge can lock your tokens and deploy a representation and then mint your users that representation and many projects opt for this model where they say okay I'm going to accept uh all these Bridge providers I'm I'm going to allow all these different Pathways for my tokens to be bridged but then it necessitates a single like adopted version of that token to be used

otherwise it's just like fragmented across all these different versions and nobody knows like what version is the real one to use so usually you want to go through some kind of like social consensus or project endorsement to designate one version as the one that everyone should use um that introduces the need for pools introduces slippage and all the complexities around like having to source liqu in order to make the ux not completely suck um the other option is that uh projects have endorsed just one version just one thirdparty Bridge makes things a little easier but you introduce catastrophic risk so those are the two main options that have been out there and uh projects

haven't really had a better alternative until now um like historically token bridging has been kind of d I see and uh it you know the incentives built on these systems are kind of skewed right like Bridge providers right now are incentivized to capture as much market share as they possibly can by funling liquidity into inefficient places or forcing projects to lock into their um proprietary standards um which makes the project have to shoulder all of that risk burden and um we just think that this is you know these two options are not great especially when we're looking forward to a thousand rollup future and um considering bridging as like a basic

primitive in this space that needs to exist so with that context set I can finally talk about RC 7281 um this is uh colloquially known as X erc20 because it's a very very simple extension on top of the existing erc20 and you'll see uh what I mean by that but first the design goals for this um token standard this open token standard is to allow tokens received by users from Bridges to always be the canonical version so everyone is always receiving the useful version of the asset and they don't have to think about like what version is everyone else using why doesn't this dap support like a usdc or X usdc or whatever um and these

tokens should be Bridge agnostic meaning that any bridge that does mint and burn should be able to Mint and burn these tokens um it does not make it it so that you know it makes it so that it's open in the sense that any Bridge can actually adopt the standard and furthermore token issuers should be able to control the token like when you have a bridge mined token the bridge deploys that token and they maintain ownership over it but the token issuers are the ones who actually should control that token um Bridges should not need liquidity right like slippage and liquidity sourcing all this is just additional headaches around um making Bridge U ux like acceptable and that's a huge problem that we we think that

should just not exist um cross-chain token interactions should be slippage free that's self-explanatory and then lastly token issuers should be able to apply their own risk models to each bridge on a per Bridge per chain basis and basically set rate limits so that way you don't have these unbounded flows and you always know at a cap like in the worst case scenario this is how much you can lose because you set those rate limits and you've done you know your DD to decide uh how much you want to allow Bridges to M and burn um that that is quite a few design goals and you might think that it actually would require some complex additions to make like an ERC compatible

with all these design goals but actually it's just like two things you just add Mitten andb burn which already exists in a bunch of extensions and you add the ability for owner to set rate limits that's it this is the entire additional interface that xc20 introduces to erc20 most of these are just getter functions and there are a couple important ones like mint burn set rate limits if you're a new token all you have to do is deploy this standard like this standard of an erc20 with these interfaces and you basically get all the benefits of those design goals that we had earlier if you are uh if you have an existing token the stand introduces this

concept of a lockbox contract which is essentially um just like the raft eth contract you deposit an existing token it wraps it and it gives you u a different version of it so you remember how I said different Bridges like um they they lock the liquidity on the original token into their own Bridge contracts we really don't want that we want there to be a shared resource for all bridges to be able to pull from if they need to unlock funds so that way you don't run into like those bottleneck issues and you don't have the custody of your actual tokens living on the bridges themselves so this lockbox contract is a shared resource across all um xcc2 bridges that bridge this specific token

and what happens is you basically wrap your existing token through the lock box it gives you a xc20 compatible version of the token instead and that's the version that Bridges actually mainten burn um part of this includes like a migration path for existing tokens right this is how existing tokens are compatible with the standard so over time through project endorsement or other social consensus um you can push for people to start using the XR C20 version and eventually liquidity will consolidate into this lockbox this is sort of the ideal end state where everyone starts using the xc20 version it's completely fungible across all different uh all different Bridges and um what this looks like to users is that

um they're just sending a cross chain enable token that is slippage free um and that is the simple migration path for existing tokens so what what this standard enables is an actual Pathway to a thousand rollup world with a million different assets without like having to go through liquidity hurdles or subjecting yourself to catastrophic like Risk vectors um of you know locking yourself into single Bridge providers it is actually compatible with canonical Bridge maximalism like you can have canonical Bridges mint these tokens all you have to do is set rate rate limits for them just like you would for any other Bridge uh and in most cases people

will probably set like higher uh rate limits for the canonical Bridges because they're safer and that is totally fine to do that um it also because of the slippage free aspect enables like real chain exraction use cases and allows for intent systems to give you optimal pricing without having to consider slippage that that is it um if you are a token project and you want to migrate or you want to adopt this standard uh which I highly recommend there are a bunch of resources on xc20 dcom um there's a link to the the official ERC that's going through the EIP process uh there's a link to a reference implementation of the token built by the defi Wonderland

team and there's also a link to a telegram group where a bunch of xc20 Builders have congregated to discuss the standard um improve on its implementations and is generally a useful place for Q&A um so shout out to the people in that group right now who are really helping us build toward this like better cross-chain future and for the rest of you who are listening I will see you there