Repository navigation
[Feature] Facet(s) to move ERC-20 liquidity across networks (Tokens Interoperability) #58
Description
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.
Activity
[-]Facet(s) to move ERC-20 liquidity across networks (Tokens Interoperability)[/-][+][Feature] Facet(s) to move ERC-20 liquidity across networks (Tokens Interoperability)[/+]mudgen commentedon Oct 20, 2025
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 commentedon Oct 22, 2025
Can I work on this?
pellyadolfo commentedon Oct 22, 2025
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 commentedon Oct 27, 2025
@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 commentedon Oct 27, 2025
@beebozy You still want to work on this? Let us know and you can be assigned to it.
Specifically I mean this:
beebozy commentedon Oct 27, 2025
Yes, @mudgen..
pellyadolfo commentedon Oct 27, 2025
@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 commentedon Oct 28, 2025
and so , no open issue(s) at the moment ...
mudgen commentedon Oct 28, 2025
@blurbeast What is the problem?
pellyadolfo commentedon Oct 28, 2025
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 commentedon Oct 28, 2025
@pellyadolfo Cool, please keep investigating. Definitely interested in cross-chain solutions that Compose can support at the smart contract level.
blurbeast commentedon Oct 29, 2025
nothing really, so i came with the intention of contributing but i have been going through every possible conversations and i love it .
mudgen commentedon Oct 29, 2025
@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 commentedon Oct 29, 2025
@beebozy Please work on this. Assigned to you.
pellyadolfo commentedon Oct 30, 2025
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:
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 commentedon Oct 31, 2025
@mudgen I have raised PR for this issue some hours ago
pellyadolfo commentedon Oct 31, 2025
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 commentedon Nov 3, 2025
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) ?pellyadolfo commentedon Nov 3, 2025
@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
mudgen commentedon Nov 3, 2025
@Rushikesh0125 @pellyadolfo I love it.
mudgen commentedon Nov 3, 2025
@beebozy Got it. Thank for doing this and I will be looking at it.
mudgen commentedon Nov 3, 2025
I am moving this thread to discussions.