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

by Eddie Ye, who leads integrations at Connect. Eddie, go on. Very good. Thank you. Thank you.

I'll wait for the slides to appear. Thank you. Hello everyone. My name is Eddie. I'm very excited to be here today to talk to you about a new ERC that I believe has the potential to solve many of the bridge problems we face today.

We have had no qualms whatsoever about building bridges, even after all the exploits, hacks and so on, because, realistically, at this point it's like a basic necessity in the ecosystem. We need a way to transfer value between all these different ecosystems and for them to be interoperable with each other. And that's where the bridge comes in. But the bridge comes with its own challenges. So let's consider some of these challenges and where they come from.

When you bridge a token, we are all aware that we are not actually moving the token from one chain to another. You are giving up your token on the original chain to obtain a representation of a token on another chain. That representation token is a right over the original token. And bridges facilitate this give-and-take process. And as a token issuer or chain that wants to incorporate other tokens into its ecosystem, the first thing you have to do is decide how to bridge this token to a chain where it does not yet exist.

There are a couple of options. You could simply build your own bridge. If you choose to do so, you will be immediately responsible for the safety of the bridge. And that is notoriously difficult. Most people and most projects will not.

It's not really a viable option. If you're going to do a rollup like Optimism or Arbitum, there's already a canonical chain there, and it turns out that chain underpins the entire security of the system. Therefore, it is actually the safest bridge . This makes it very common and reasonable for tokens to be bridged through canonical bridges. However, canonical bridges do not exist in all chains, only in those roll-ups.

Therefore, if you are a token issuer and want to go to all these new trendy chains that exist, you need to think about something else if you want to go to those other chains. And in the world of EVM, canonical bridges only connect the chain to Ethereum. Therefore, if you want to switch from Optimism to Arbitrum, for example, you would have to bridge from Optimism back to Ethereum, endure the 7-day withdrawal period, and then reconnect it or connect it to Arbitrum. And those two jumps are relatively expensive because canonical bridges are expensive. Canonical bridges offer this safe option, but you still need to think about other alternatives for other bridges.

Historically, token issuers and projects have basically chosen one of two practical cross-chain strategies. The first one is simply to use multiple bridges, right? Therefore, you can use the canonical bridges, you can use a variety of third-party bridges, all bridges, and in theory, that should allow you to bring your token to all existing chains. And, generally, the canonical bridge version becomes what we call an adopted version of the token; Because, every time a bridge implements a different representation of your token on a different chain, you end up with millions of these different tokens that represent the same thing on the source chain, but are different tokens in themselves are different tokens in themselves . Therefore, what you really want is a widely adopted version that everyone uses, that all your tokens, all your users have, all DEX listings, and all DAB support.

Therefore, as a project, you can accept that the canonical bridge version generally becomes the adopted version because everyone in the ecosystem considers it the most secure , and therefore usage naturally converges on that canonical version. Um, or in other chains where there isn't a canonical version, you can try to back up one of the bridged versions and try to get everyone to use that version because it's more convenient when the DAPs don't have to list like 14 different versions of the same token and everyone communicates with the same version of that token. Um, the problem with this is that users who bridge through other bridges that don't support that version have to get the version that everyone else is using at some point. So that introduces liquidity funds into this conversation. And liquidity funds introduce slippage.

So now, all the other bridges, as part of this last-mile delivery step for you to deliver to your users the actual version of the token they want to use on that chain, have to have an exchange involved between the bridge's minted version and the adopted version of the token that everyone else is using. Obviously, this causes cross-chain transfers to incur slippage many times, and aside from slippage being an additional cost to the user, it actually breaks composability in many cases where you need to know exactly how many tokens you are getting on the destination chain. It is not deterministic when you have slippage in the equation. Furthermore, this model means that, because you have pools, you now need to obtain a large amount of liquidity to minimize slippage. And if you're a small project, you're not going to drive enough bridge volume through your token to generate enough revenue to incentivize LPS to create these deep pools.

So, you're simply going to have difficulty generating liquidity. If you're a larger project that relies on stacks of venture capital, yes, you can simply throw money at it and add incentives, and that makes that problem a little easier. But it's a terribly inefficient way to use capital and it simply doesn't scale when you think about what will happen in the future with a thousand accumulations with a thousand different assets in a thousand different chains. Even investing money doesn't solve it. So, there is another major problem with this model, and that is when bridges lock tokens on the original chain or source chain, as we sometimes call it.

This origin chain is where the original token is implemented. And each time the bridges lock that token and mint a different representation on a different chain, they actually fragment that liquidity on that origin chain because each bridge contract now holds a portion of the total canonical collateral on the origin chain. So if you want to move a relatively large amount of tokens back to the origin chain through a specific bridge, it's entirely possible that that bridge doesn't have the canonical assets—the collateral locked on the origin chain—to unlock for you, which breaks that guarantee that your tokens are claims you can reclaim at origin at any time. So, this multi-bridge model introduces slippage, which is a problem and really complicates things, but it allows you to access almost every chain out there. The other option is much simpler.

Basically, it's just a provider lock . So, as a project, you choose a third-party bridge, designate them as your backed bridge, and the minted version of their token becomes the adopted version. You consider that version to be the only legitimate one in each chain that they accept, and it makes things easier because that bridge now only has one representation, and that bridge owns them all in each chain. So, if you need to go from L2 to L2, the bridge can simply burn and mint those tokens directly. There's no need for pooled funds or liquidity, and yes, that sounds great because there's no slippage, but you can also only go to the chains that bridge supports.

But more importantly, you 're now tied to your entire token, which is tied to that third-party bridge's security model, and that introduces systemic risk. You don't like a classic case study like the multiple chains one, where projects knew the risks of a third-party validated bridge, but had no better alternatives in many other chains they wanted to go to. So, they minted their tokens across multiple chains, linked them to any asset system, and when things came crashing down, their token is now unbacked and they have no control over the token. They have no resources. That's it .

So, you're locking yourself into this proprietary token standard that introduces systemic risk from the bridge itself, and you can't go back to that system. It is very difficult to escape the walled garden of a proprietary token standard minted by a single bridge, especially if you give it unlimited minting privileges and unlimited flows through its bridge. Obviously, this option isn't very good either. In summary isn't very good either. In summary , we have bridges that mint tokens of representation on other chains.

In fact, they are free to do so. It's a model without permission. Any bridge can lock your tokens and implement a representation and then mint that representation for your users. And many projects opt for this model where they say, "Okay, I'll accept all these bridge providers. I'll allow all these different pathways to connect for my tokens, but then you need to use a single adopted version of that token.

Otherwise, it gets fragmented across all these different versions, and nobody knows which version is the one that should actually be used. So , you usually want to go through some kind of social consensus or project approval to designate one version as the one everyone should be using. That introduces the need for pools, introduces slippage, and all the complexities that come with having to get liquidity so that the user experience isn't completely bad. The other option is that projects have endorsed only one version, only one third-party bridge, which makes things a little easier third-party bridge, which makes things a little easier but introduces catastrophic risk. So, those are the two main options that have existed, and projects haven't had a better alternative until now.

Historically, token bridging has been kind of risky, and, you know, the incentives created in these systems are a bit skewed, like the..." Bridge providers are currently incentivized to capture as much market share as possible by funneling liquidity to inefficient places or forcing projects to lock into their proprietary standards, which means the project has to shoulder all that risk. And we think both of these options are bad, especially when we expect a future of thousands of accumulations and consider the bridge a basic primitive in the space that must exist. So, with that context established, I can finally talk about ERC 7281. This is colloquially known as XERC20 because it's a very, very simple extension of the existing ERC20.

And you'll see what I mean by that. But first, the design goals of this token standard, this open token standard , are to ensure that the tokens received by bridge users are always the canonical version. This way, everyone always receives the useful version of the asset and they don't have to worry about which version everyone else is using. version everyone else is using. Why isn't this DAP compatible with USDC or XUSDC or whatever?

These tokens should be bridge-independent, meaning any bridge that mints and burns should be able to mint and burn these tokens. It doesn't do this in an open way, in the sense that any bridge can adopt the standard. Furthermore, token issuers should be able to control the token. Like when you have a token minted by a bridge, the bridge implements that token and retains ownership. But token issuers are the ones who should really control that token should really control that token .

Bridges shouldn't need liquidity, right? Like slippage and liquidity raising. All of this is just additional headaches to make the bridge user experience acceptable. And that's a huge problem that we believe shouldn't exist. Cross-chain token interactions should be slippage-free.

That's self-explanatory . And finally, token issuers should be able to apply their own risk models to each bridge on a per- bridge, per-chain basis and essentially set rate limits. That way you don't have these unlimited flows, and you always know, at a limit, like in a worst-case scenario, how much you can lose because you've You've established those rate limits and have your DD decide how much you want to allow the bridges to issue and burn. Those are quite a few design goals, and you might think it would actually require some complex additions to make it, as an ERC, compatible with all of these design goals. But really, it's just two things: you just add minting and burning, which already exists in a bunch of extensions, and you add the ability for the owner to set rate limits.

That's it. This is all the additional interface that XRC20 introduces to ERC20. Most of these are just obtaining functions, and there are a couple of important ones, like minting, burning, and setting rate limits. If you're a new token, all you have to do is implement this standard as an ERC20 standard with these interfaces, and you basically get all the benefits of those design goals we had before. If you have an existing token, the standard introduces this concept of a vault contract, which is essentially like Waft's ETH contract.

You deposit an existing token, it wraps it, and gives you a A different version of the same token. So, remember when I said that different bridges lock up the liquidity of the original token in their own bridge contracts? We really do n't want that. We want there to be a shared resource that all the bridges can draw from if they need to unlock funds. That way, you don't run into those bottleneck issues, and you don't have custody of your actual tokens in the bridges themselves.

So, this vault contract is a shared resource among all the XCRC20 bridges that connect the specific token. And what happens is that you basically wrap your existing token through the vault. It gives you an XCRC20-compliant version of the token instead. And that's the version that the bridges actually mint and burn bridges actually mint and burn . Part of this includes a migration path for existing tokens, right?

That's how existing tokens become compliant with the standard. Then, over time, through project endorsement or other social consensus, you can push for people to start using the XCRC20 version, and eventually, the liquidity becomes available. It will consolidate in this secure vault. This is the ideal end state where everyone starts using the XRC20 version. It's completely fungible across all different bridges, and what this means for users is that they're just sending a cross-chain-enabled token that has no slippage.

And that's the simple migration path for existing tokens. So, what this standard enables is a real path to a world of a thousand stacks with a million different assets without having to go through liquidity hurdles or submit to catastrophic risk vectors , like locking into single-bridge providers. It actually supports canonical bridge maximalism. As if canonical bridges could mint these tokens. All you have to do is set velocity limits for them, just as you would with any other bridge.

And in most cases, people are likely to set higher velocity limits for canonical bridges because they're more secure, and it's perfectly fine to do so secure, and it's perfectly fine to do so . And also, because of the slippage aspect, it enables real cross-chain interaction use cases and It allows intent systems to provide you with optimal prices without having to consider slippage. That's it. If you're a token project and want to migrate to or adopt this standard, which I highly recommend, there are many resources at xrc20.com.

There's a link to the official ERC, which is going through the EIP process. There's a link to a reference implementation of the token built by the D5 Wonderland team. And there's also a link to a Telegram group where a group of XCRC20 developers have gathered to discuss the standard, improve their implementations, and generally—it's a useful place for questions and answers. So, a shout-out to the people in that group right now who are really helping us build toward this better cross-chain future. And for the rest of you listening, I'll see you there.