[READY TO VOTE] Enabling xERC20 Tokens Support on the Superchain Mission Request

Governance Fund Missions 🏹
,
1

Delegate Mission Request Summary:
Enable xERC20 tokens support on the Superchain by constructing a Custom Bridge for optimal xERC20 token routing.

S5 Intent Please list the Intent your Request aligns with here: 2 Grow the Superchain (Interoperability research)

Proposing Delegate: SEED Latam delegation team

Proposal Tier: Ember

Baseline grant amount: 15k OP

Should this Foundation Mission be fulfilled by one or multiple applicants: One

Submit by: To be set by Grants Council

Selection by: To be set by Grants Council

Start date: ASAP

Completion date: Estimated 6 weeks from starting date

Specification

How will this Delegate Mission Request help accomplish the above Intent?

The adoption of xERC20, being completely bridge agnostic, helps the whole web3 ecosystem by making crosschain liquidity more capital efficient and secure. It helps projects to avoid being locked into 3rd party bridges which, if compromised, can jeopardize even secure layers like Optimism.

The work fits within the Superchain vision, as it helps to unify liquidity across OP Mainnet and potentially other OP chains, using both native and 3rd party bridges.

The mission request will target OP Mainnet, OP Chains, which we refer to as Superchain.

What is required to execute this Delegate Mission Request?

  • Build the xERC20 token bridge on top of the Superchain stack existing base messaging functionality with the specifications below.
  • Provide instructions and specifications to enable shared token mapping across the OP Mainnet (note that there already a Superchain token list)

How should the Token House measure progress towards this Mission?

  1. Submit specifications
  2. Custom token bridge - testnet deployment
  3. Token registry - testnet deployment
  4. Complete Documentation
  5. Custom token bridge - OP Mainnet deployment

How should badgeholders measure impact upon completion of this Mission?

  • Number of xERC20 tokens bridged to OP Mainnet (and aligned OP Chains)
  • Number of third party bridges integrating xERC20 into OP Mainnet (and aligned OP Chains)
  • Volume of xERC20 tokens into OP Mainnet (and aligned OP Chains)
  • Volume (real usage, economic activity) of xERC20 tokens inside of OP Mainnet (and aligned OP Chains)

Have you engaged a Grant-as-a-service provider for this Mission Request?
No.

Has anyone other than the Proposing Delegate contributed to this Mission Request?
Yes, the Connext team has contributed to drafting this Mission Request.

Appendix

A solution criteria

The Optimism canonical bridge implements two components:

  1. The underlying messaging system between domains
  2. The application built on top of the above acts as the canonical token bridge. Typically, this application custodies tokens on L1, and then mints a representation of that token on L2.

Adding a custom bridge on the messaging layer is already supported. The xERC20 token bridge needs to sit at the same level as the canonical token bridge, to avoid edge cases around token minting/locking.

The xERC20 token bridge needs to be able to:

  • Identify if it has not reached its rate limits, and if so
  • Wrap the token into an xERC20 if needed
  • Burn the xERC20 version and mint its representation on Optimism

Additionally, a custom UI should also appropriately route xerc20 transfers. This helps to avoid the following cases:

  • An xERC20’s underlying ERC20 token is locked-and-minted across chains leading to a new bridged-ERC20 representation created on the domain that is infungible with the token-issuer-defined canonical token.
  • An xERC20 is incorrectly routed to the canonical lock-and-mint bridge instead of the xERC20 bridge contracts on the home domain, which once again creates an incorrect and infungible representation on the remote domain.

A component for a possible bridge UI that can be opted in by any interface of the Superchain should provide access to a mapping of the self-identified xERC20 tokens and establish appropriate route.

Resources

6 Likes
2

Note: This mission request is in some way related to previous work between Connext and Wonderland. If there are any potential conflicts of interest or bias during the process with respect to any of my duties within the Collective, I will communicate them promptly.

4 Likes
3

My problem with this is that it’s an opinionated approach to token standards and we’re not there yet.

You’re explicitly suggesting a token standard and bridge made by Connext so this is presuming a particular way forward with significant implications for crosschain interoperability during a time when there’s ongoing research on how the Superchain is going to work. I have no problems with this token standard but I think this mission request is too tailored. @MinimalGravitas put out a mission request that I think Connext could apply under if it’s approved.

I could be wrong, but I think this kind of thing is better managed in close coordination with OP Labs and those working on infrastructure.

5 Likes
4

An important note is that ERC-7281 is a standard that exists independently of Connext and any other bridge. This standard is the most impartial way to bridge tokens because its owner (whether it be a DAO or a company) has control over the issuers supported (canonical, third parties…). That’s why it’s also known as Sovereign Bridged Tokens. Said this, I believe that it is sufficiently distinct and can coexist or align with any future developments on Superchain.

So, the mission request only needs to adapt this standard to work with the canonical bridge, and there is no need for any intervention from OP Labs afaik. The most interesting part of this is creating a component bridge UI that allows for the minting of this custom token. This UI ensures that users bridges the tokens with the correct mapping and not via the standard canonical method.

But happy to see more eyes on this, I’m sure @maxlomu can provide more insights.

3 Likes
5

I’m aware of how open ERC-7281 is - and as I said I have no problems with it. In fact my understanding is that it’s probably among the best options we have.

But we have ongoing research dealing with this exact issue, and presuming the answer and funding its building, likely by Connext (you mentioned the bridge UI, which again is opinionated) isn’t in my view in scope for what we’re doing here.

And the fact that you need this to link up with the canonical bridge is exactly why you need intervention from OP Labs. It needs to fit into the flow and tokenlist review that the canonical bridge has.

Meanwhile, Optimism is dealing with several bridge providers, some of whom don’t like ERC-7281. Pushing openly for this standard through a granted mission request – and in effect handing the contract to Connext – without coordination with those other bridge providers could lead to unforeseen frictions.

There is the RFG research crosschain and token standard research being done by Norswap in collaboration with OP Labs, and again there is the other much more path-agnostic mission request posted by @MinimalGravitas. My suggestion to Connext is to link up with @norswap and his team and determine how they could plug in.

4 Likes
6

Out of curiosity, by the way, what does this mission proposal have to do with Wonderland?

2 Likes
7

Sure, it’s because the references at the appendix (pretty minor but I mention it for reasons of maximum caution).
New: edited to include “bias”.

2 Likes
8

Hey @jackanorak, many thanks for your comments: truly appreciate your engagement in this proposal.

I would like to add more clarity on some aspects:

  • The mission request comes from the specific needs of projects/token issuers that have explicitly requested support for their xERC20 tokens to be bridged to the OP chains via the official bridges.
    Connext doesn’t benefit directly from this standard; it’s an open standard whose approach has received wide support, and in fact it’s already being used by plenty of projects with other bridges.

  • We could try to work within the research and implementation mission, however as this proposal is already clearly defined, scoped out and with clear market needs from several projects, I believe it would make sense to keep it separate and not overcrowd the other research.

  • The work required can be completed by any team/organization. I would advocate for an organization different than Connext - that’s actually the ideal scenario.

  • The goal is to create a custom bridge implementation and a component for the UI that can be used by the various teams of the Superchain. The UI doesn’t need to be upgraded for the mission to succeed, but the objective is to make life easier for teams if they want to. That said, if that’s a concern I would also support the removal of this part from the mission.

Thanks and looking forward to more feedback

2 Likes
10

Without opining on the merits of this particular mission request, people doing parallel research probably shouldn’t be too worried about a 15,000 OP-budget exploration of another option. We would prefer to see this debated on merits other than appealing to the sunk cost fallacy.

1 Like
11

This isn’t exploration - it’s implementation. That’s the issue.

1 Like
12

Remember that mission requests can’t rely on Foundation to OP Labs action or support.

I’m not saying this is the case but if it is it must be changed.

3 Likes
13

Hi everyone! I am an employee of OP Labs and speaking on my own behalf. My general opinion is that this can become a good, extra option for advanced users and token issuers on OP Mainnet. However, I cannot guarantee that it will be integrated as the Superchain roadmap, or be integrated in OP Stack canonical tools.

We’ve always imagined folks building more advanced bridges on top of our messenger contracts, parallel to our Standard Bridge. So instead of solving “Superchain bridging”, I would love to see this mission and its message lean into extensibility (vs default)!

6 Likes
14

Thanks for everyone’s input here.

I’d like to address some misunderstandings and propose some adjustments based on feedback received.

This mission is not about enshrining xERC20s into the canonical bridge.
Instead, it’s about supporting a growing requirement from builders: allowing their tokens to use the Optimism bridge while maintaining a unified token across chains.

This is a use case for example for tokens like AlUSD and HAI that are natively minted on Optimism, but are not directly compatible with the OP bridge, because the bridge assumes that it unilaterally controls the token’s supply.

This means the token issuers (including every xERC20 token issuer) need to do the same custom work over and over to integrate the OP stack bridge (even if their primary bridge is some other system).

Importantly, this integration aligns with Optimism’s messaging original design and can be achieved permissionlessly, as described in Optimism’s documentation.
The aim here is to establish shared infrastructure as public good to eliminate repetitive efforts for token issuers, justifying the need for a Mission Request.

After discussing with Norswap, we also confirmed that there’s no overlap between his work and the xERC20 mission.

Lastly, as OP Labs shouldn’t be involved at any stage, I would recommend dropping the UI requirements for now, and presenting them as an optional add on in a future stage.

15

I’m not clear - are you saying that your mission request as proposed does this, or are you suggesting that the proposal be made more generic to focus on the problem set and not the solution?

it’s difficult to pin down what’s being proposed now. on the one hand you are saying there will be changes and on the other you’re still leaving the bridge UI as an “optional” thing for the future, which presumes xerc20 uptake

16

Yes, that’s the purpose of the mission.

Extend the functionalities of the Op stack messaging contracts to allow xERC20 token issuers to opt in the Optimism bridge as well.

The UI component instead should be left out of the requirements.

17

I am an Optimism delegate with sufficient voting power and believe this proposal is ready to move to a vote.

1 Like
18

Hey @Joxes – just wanted to flag this as a proposal that still needs delegate approvals in order to move to a vote. If you are no longer interested in pursuing this proposal – please disregard this message. In order to see the delegates assigned to your proposal those can be found here. The deadline to provide feedback and approvals for Mission Requests is February 7th at 19:00

Cheers!

19

Since I’ve been mentioned here, I thought I’d give my opinion.

The interop research covers a lot of grounds, but within that we can distinguish a messaging layer and a token layer (amongst other things!)

The messaging layer is concerned with transferring messages between chains - this is pretty low-level & for some architectures, ties in deeply to chain architecture (especially if one wants to minimize the additional trust assumption on top of the source & destination chains).

The token layer, on the other hand is concerned with representing bridged tokens across chains. The main issue here is that multiple underlying message bridges lead to multiple token representations. In the simple case that’s two bridges from the same source chain to the same destination chain. A bigger problem for the superchain are “token paths”: a token bridges from Ethereum to Base then to Optimism would have a different representation than a token bridged from Ethereum to Optimism directly.

xERC20 is a standard on the token layer, which allows multiple underlying message bridges to feed into the same ERC20 token, solving the above issue. Without something like it, Ethereum-native tokens would need to be bridged to Ethereum & back instead of being able to be bridged within the source chain.

To the best of my knowledge, xERC20 is the only standard that exists to tackle this challenge. It has a few properties I consider important:

  • It’s an open standard following the ERC process on which anybody can input.

  • (related to the above) it is documented & specified

  • It is not tied to a specific bridge solution

  • It has buy-in from multiple bridge providers

Importantly, the current proposal does not require any enshrinement, at the protocol level or otherwise. The proposal it to (1) fund the creation of a custom xERC20 compatible custom bridge (token layer) on top of the OP stack bridge (messaging layer) and (2) map xERC20 tokens on Ethereum & the various Superchain chains (e.g. a token $X on Ethereum & its various wrapped xERC20 representation on the superchain chains).

Both these things are permissionless, and are public goods that benefits existing users of the standard & promotes future use of the standard.

If another token-layer standard were to emerge that had significant innovations and/or buy-in (while maintaining a certain set of values like permissionlessness), I would also support funding its infrastructure like this.

This proposal does not entail enshrinement, and significantly, it should not even be taken as a blessing of the standard (that is a different discussion entirely).

So I’m very positive about funding this, as promoting open standards is a good thing, and this standard solves real issues for token bridging. It also does not require any enshrinement (which would require a much more careful discussion).

6 Likes
20

Thank you all for the feedback and the support - Appreciate you sharing your opinion and clarifying how this mission is positioned @norswap

@web3magnetic @Joxes - thanks for the support.
@brichis @mastermojo @troy(? Not sure who from Synthethix is looking at this) I’ll reach out to understand if there are any final concerns before getting your approvals and moving to a vote

1 Like
21

Following these comments from Norswap who is researching interop standards (via the RFG process), I’d be happy to support this. Especially as it tackles an area that doesn’t enshrine it into Optimism/Superchain, and is only seeking out permissionless areas which can help support Superchain/OP Projects.

I am an Optimism Delegate with sufficient voting power and I believe this proposal is ready to move to a vote. @maxlomu - Synthetix Ambassadors btw.

3 Likes