[Feature] Facet(s) to move ERC-20 liquidity across networks (Tokens Interoperability)

[pellyadolfo]

It would be great having some ERC-20 extension facets which allows moving liquidity across different chains out of the box. This would deliver cross-network interoperability at contract level embedded in the platforms itself. From facet in one chain to counterpart facet in other chain.

I investigated some approaches in the past but most require quite a lot of complexity in development and maintenance. Some of them are:

• One possible solution would be using facets working as custom bridges.

• Another option would be interchain messaging protocols as CCTP, CCIP, CCP, Wormhole, LayerZero Messages, Sigma GMP, Nomad, Celer IM, AnyCall

• Another solution would be using a layer (intermediary chain) as Axelar GMP, Entangle, Hyperlane or Push

• Another option would be using Intends

• Also we could use native token transfers with Wormhol Native Token Transfer, LayerZero OFT, Axelar ITS

This would allow tokens to be deployed in the chains chosen by the issuer without the headaches. In the worst case, some of previous solutions can be included in the standardized facets. In the best case, some new approach could use facets technology natively. Well, food for thought.

[mudgen]

Yes, this is valuable functionality.

What about implementing this standard: ERC-7802: Token With Mint/Burn Access Across Chains. OpenZeppelin has it implemented here: https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/token/ERC20/extensions/draft-ERC20Bridgeable.sol

We could implement it too.

[beebozy]

Can I work on this?

[pellyadolfo]

In my view, all the existing interoperability solutions have been created for contracts offchain that have to be deployed one by one. Compose is different. Compose is a change of paradigm. Compose has an unique potential to have contracts in every single EVM-based chain communicating to each other. For projects this means something totallly new: they wont have to "marry" a chain anymore as Compose would work as an abstraction layer. And thats the incredible potential. No just moving existing contracts onchain but building an abstraction layer which is already deployed and trusted. Now, I have the feeling that Compose can improve existing interoperability solutions, both, in terms of delivering business cases out of the box, so projects can just plug and play across any network, and also technically because the contracts are already deployed (maybe some zk bridges, maybe using bitcoin as middleman, I do not know...?).

The solution that mainstream has given to interoperability does not comply with decentralization requirements. Stablecoins argue that they are in every network but, after, you have a guy doing manual mints and deployments and a centralized oracle monitoring prices. And this is not a serious foundation to claim decentralization.

On the other hand, the existing technical mechanisms, either messaging, bridges, layers, intends.... require adhocs solutions and reinventions of the wheel with inherent risk of failure and this discourages investors.

So, I am not against these basic technical mechanisms being included in Compose. Maybe they will be needed. But I think Compose would shine by delivering real business cases as an abstraction layer that investors and projects can trust because they know they can plug and play and just works.

when I asked I was not looking for a quick solution (because it wont adddress existing issues in blockchain technology) but to open the vision of "change of paradigm to abstraction layer" (with the potential to address these issues)

[mudgen]

@pellyadolfo Sounds great. My cross-bridge plan right now is to use CreateX to make it so that anyone can deploy our facets (smart contracts) on any EVM-compatible blockchain to the same address. So for example our ERC721Facet will exist on many blockchains at the same exact blockchain address.

I also want to make it easy for people who use Compose to deploy their diamonds at the same address, across many blockchains.

[mudgen]

@beebozy You still want to work on this? Let us know and you can be assigned to it.

Specifically I mean this:

What about implementing this standard: ERC-7802: Token With Mint/Burn Access Across Chains. OpenZeppelin has it implemented here: https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/token/ERC20/extensions/draft-ERC20Bridgeable.sol

[beebozy]

Yes, @mudgen..

[pellyadolfo]

@mudgen ERC-7802 looks the right ERC standard for this case.

What I am trying to understand is how the underlying trust model fits in this interoperability goal. The underlying trust model is the offchain mechanism on how blockchains interoperate. None of the existing models is good enough at current state of arts and, as a consequence, we have the current fragmentation. And fragmentation (apart from tokenomics) is destroying adoption.

This link is not exhaustive but is ok ilustrating the problem: https://www.cryptoeq.io/articles/blockchain-interoperability-solutions (see the table) The trust model offered by Axelar, Wormhole or LazerZero is not good enough as you need to trust third parties. It seems the future is some flavour of ZK Proofs and, therefore, trust mathematical computations instead.

Despite being an offchain mechanism, it could impact the interfaces used by the smart contracts so it would be good build over a good long term vision for the interoperability use case. Derived topics as bridges, messages, intents, atomic swaps, solvers, interchain token services, liquidity transfers, chain abstraction, account abstraction..... are as good as the underlying trust model that was adopted. Even when is not a evident issue for a smart contracts library, maybe an assumption on the trust model can impact the used interfaces. And maybe the outcome of the investigation is ERC-7802 but I am not there yet, e.g. I have not verified that ZK Proofs (as the more promissing trust model) will use ERC-7802. I can open a discussion to make this assumption for the library if you want, or maybe also consider other possible trust models.

TLDR: defining a trust model supported by Compose as use case is an issue? (I have not answer yet)

[blurbeast]

and so , no open issue(s) at the moment ...

[mudgen]

and so , no open issue(s) at the moment ...

@blurbeast What is the problem?

[pellyadolfo]

The thing is that after implementing ERC-7802, is needed to find a product that supports this standard which was created by Optimism+Uniswap. I see e.g. Astar will support it. But still limited providers.

I am much more impressed with Hyperlane allowing messages between 150 chains. Hyperlane also support some ERC standards (e.g. ERC-5164) and is offering ZK as trust model.

What I do not know yet is what is the use cases to build but Hyperlane looks a solid proposal for interoperability. Needs more investigation.

[mudgen]

@pellyadolfo Cool, please keep investigating. Definitely interested in cross-chain solutions that Compose can support at the smart contract level.

[blurbeast]

and so , no open issue(s) at the moment ...

@blurbeast What is the problem?

nothing really, so i came with the intention of contributing but i have been going through every possible conversations and i love it .

[mudgen]

@blurbeast Great! Would be glad to have your contributions! Feel free to open a discussion if you have some ideas of things you might want to implement or add to Compose.

[mudgen]

@beebozy Please work on this. Assigned to you.

[pellyadolfo]

Well, there is a large degree of heterogeneity. for interoperability providers and this is known. To ilustrate the problem, I am posting below some examples on how different providers use different interfaces to do the same action, in this case, sending a message:

• Wormhole's sendPayloadToEvm
• Celer's sendMessage
• LayerZero's send
• Axelar's sendMessage
• Analog GMP's sendCrossChainMessage
• Hyperlane's dispatch
• Zetachain's send
• Hyperbridge's dispatch
• Sygma GMP's sendTransaction
• Nomad's dispatch

and so on. Every provider brings different features in terms of cost, supported chains or trust model. Some of them support ERC standards but there is not a major agreement on it.

It would be great standardizing to decouple the code from specific providers, but I have 2 questions on this:

• I think this must be done in term of use cases, i.e. having a list of use cases > defining interfaces > building implementations for the different providers

• How to do this without having a big mess of dependencies (specially without inheritance)

[beebozy]

@mudgen I have raised PR for this issue some hours ago

[pellyadolfo]

The status of ERC-7802, is that it was created by Optimism, included in their SuperchainERC20, even adopted by OZ in their wizard. Here describes the lifecycle. It can be added to Compose... but... is draft status and only adopted by Optimism. Maybe someone finds a valid use case.

I think there is a whole bunch of possible use cases in interoperability but they do not have yet a standard.

[Rushikesh0125]

Hey @pellyadolfo, this thread has been pretty resourceful and full of insights.

I was also thinking about a generalized facet for sending and receiving messages, which can use any interop protocol. An intended standard for this was proposed by Interop Labs, Axelar, and OZ - ERC7786.

Can we build something similar as a base and then build on top of this for token bridging?

How to do this without having a big mess of dependencies (specially without inheritance) ?

• Till now, while using diamond, I have been modifying the protocol contracts and moving their storage to diamond's storage. kind of converting those to libraries and exposing functions in facets for any external function.

[pellyadolfo]

@Rushikesh0125 Yes, this is the kind of solution I was thinking. Not just one "bridge" use case here. In theory all token functionalities should become multichain and Diamond Standard ERC-2535 has a priviledge on this over regular solidity to build an abstraction layer. on top of all EVM chains and all existing interop providers. So, yes, I buy your solution, I also thought of it. At the medium term we could identify more use cases to make all functionalities single chain and multichain and, maybe, define some more specialized ERC standards and specialized facets. At the short term a basic bridge use case as a facet using ERC7786 can be a good starting point, with the difference with ERC-7802 that the bridge logic is transparent for the retail investor / holder. I think Compose would rock if also delivers multichain features out of the box.

@Rushikesh0125 Elaborating a bit more on the specific need, maybe we can open a discussion issue for the case but, my opinion is that is better specialized facet per feature (+ maybe new ERC standard) (so the token issuer/assembler can add/remove decoupled functionalties) than a generic messaging facet that could become a mess with many use cases

[Rushikesh0125]

Yeah, i totally agree with your view of specialized facets which are need specific.

My only intention with CCM as base is that the CCM is the basic building block of almost every interop/multichain utility from bridging to even cross VM intents in some implementations.

But yeah i agree with implementation of facets for each utility onr by one which will also help us implement them neatly.

IMO the roadmap should look like a base generic gateway(shld be able to connect with relayers/core contracts ) -> which implies ERCs like 7786, 7802 -> ccm, bridging, reads, etc
(Very rough)

Lemme know what you guys think @mudgen @pellyadolfo

[pellyadolfo]

Agree with the goal. Regarding implementation there many points to discuss, I am not aware on token communication patterns as yet. I am aware of these patterns on other systems out of blockchain. Some generic ideas:

• Ideally every token should have the same address in all networks, but this is not always feasible if somebody takes an address and deploys a fake token. But is possible to accept this as a general case with some stored exception. This would simplify how every token know about each other (e.g. stored exception ? use exception address : use general case same address). Anything different from CREATE2 / CREATE3 perspective?

• should there be a master operator "token instance" (orchestration) or every "token instance" can operate (choreograophy) . Maybe depends on the use case.

• Interop providers are focused on messages so they created a message centered ERC7786 . But a generic sendMessage() function would couple many features in the same facet and this does not sound good pattern. Specialized facets by feature with single responsibility should be easier to CRUD.

• But, in the meantime we properly understand a use case, having a generic sendMessage() sounds ok to me mostly for development purposes. I would not move a generic function to releases because the coupling of features.

• I think every facet should be dedicated to a single use case. I would call use case to something with business value (e.g. transfer liquidity, rebalancing liquidity, aggregating liquidity, multichain vault balance, multichain change of owner ....). I would not call "a read" or "a message" a use case.

• Maybe we can dedicate this open discussion to identify possible interop use cases and, after, open specific discussion per use case. If so, should we open a different discussion for e.g. "transferring liquidity between token instances of the same token" or "rebalancing multichain liquidity" and leave this for generic interop discussions? I can rename this accordingly.

[Rushikesh0125]

Regarding modes of operation or arch its upto devs/protocol teams, how they want to design it based on their tokenomics, and liquidity strategies.

yeah, it sounds good to cater certain needs separately in a loosely coupled manner. would love to hear a plan to implement this so we can start drafting and implementing stuff.

[pellyadolfo]

agree, still many unknowns to start implementing. Many ideas but trying to release step by step so it can make sense. I also think Multichain-Compose-Tokens should have a well defined common structure, introduce some definitions and common practices, etc. Just because there should be an assembly of facets and some assumptions are needed. And this requires some previous tecnical discussions. Then we can start building use cases as facets.

[pellyadolfo]

@Rushikesh0125 Regarding "upto devs/protocol teams, how they want to design it based on their tokenomics, and liquidity strategies" there are only a few possible cases: memecoin, utilty token, security tokens/RWA, stablecoin, NFT and maybe maybe some other, but not more. If you do not deliver tokenomics preprinted out of the box, with flexibility, in my opinion, dev teams can argue that they wont need Compose, holders / retail investors wont know / trust about Compose and the advantages of standardization and presence in networks will be gone. The opportunity I see is packaging proven and recognized good practices as reusable models to just assemble, probably configure and be ready to go.

[mudgen]

@Rushikesh0125 @pellyadolfo I love it.

[mudgen]

@mudgen I have raised PR for this issue some hours ago

@beebozy Got it. Thank for doing this and I will be looking at it.

[mudgen]

I am moving this thread to discussions.

[pellyadolfo]

I have a question on this. In order to use external relayers, we need to invoke external interfaces as

• https://github.com/wormhole-foundation/wormhole-solidity-sdk/blob/main/src/interfaces/IWormholeRelayer.sol

• https://github.com/celer-network/sgn-v2-contracts/blob/main/contracts/message/framework/MessageApp.sol

• https://github.com/axelarnetwork/axelar-gmp-sdk-solidity/blob/main/contracts/gateway/AxelarAmplifierGateway.sol

• https://github.com/hyperlane-xyz/hyperlane-monorepo/blob/main/solidity/contracts/interfaces/IMailbox.sol

• https://github.com/nomad-xyz/monorepo/blob/main/packages/contracts-core/contracts/interfaces/IUpdaterManager.sol

I have to compile an extense list of interfaces and mechanisms (sometimes is an external contract, sometimes it has to be extended..).

I suppose a different facet would deal with each provider and all of them would implement the same function (e.g. transferLiquidity(...)) so they can be switched. How can Compose accommodate invokation to external libraries like these ones? Have you thought a mechanism? Some external project? Just include the interface in Compose? (licenses?). Just invoke the functions by name and contract address without contract compilation?

[Rushikesh0125]

For case where contracts need to be extended, we will need them to be converted into a facet. this will enable anyone to use them.

And for external contract calls, interfaces is the solution. Which already provided by oracle libraries most of the times. For eg, wormhole relayer, layerzero endpoint v2

[pellyadolfo]

Yes @Rushikesh0125, as "interfaces is the solution" we need to include somehow the interfaces in the project and these are external dependencies that at the moment does not exist. So, some kind of strategy is needed. On the other hand, including the logic that uses interoperability as part of compose I think is mandatory to prevent misuse. If developers or issuers can misuse Compose to cheat retail investors, it wont be adding any new value, in my opinion.

[pellyadolfo]

Omnichain Smart Contracts can give some ideas

[pellyadolfo]

I am reading Nick again and I realise, built-in interoperability is not in the initial plan of Compose (unless we find a way). I think it will be needed to get blockchain back... and Compose would get the highest benefit than any other framework. Maybe, instead of wrapping the relayers, Compose can do something else to verify a proper usage of relayers.

[mudgen]

I am interested in what might be the best ways to implement cross-chain interoperability.