[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.