What do you want Compose to do for you?

[mudgen]

Compose will evolve in large part based on what and how people would like it to help them create smart contract systems. Tell us what you would like Compose to do for you.

[pellyadolfo]

I am giving a deep thought on how to achieve chain abstraction, as it would open the pandora box for smart contracts and facets. Whereas it would be possible to create smart contracts for zk proofs or merkel proofs, I find blockers outside of the EVM itself, at relayer scope, that compromise decentralization. I am stuck on this fragmentation issue for long time, as most of blockchain development I think.

[mudgen]

Okay, let me know how this developers. Today a pull request came in for adding a ERC-7802 Facet for Cross-Chain Token Interoperability #158

[pellyadolfo]

The problem I see on this ERC-7802 interface is that you either operate it manually or rely on a filter implementation to operate it.

• Operating it manually, breaks the decentralization principle (which BTW is what all RWA stablecoins do) and the consistence of the total supply is not guaranteed. I do not see how to convince retail investors / holders by following this path.

• Today, you cannot rely in a filter to invoke some implementation of this interface unless you use Optimism SuperchainERC20 (which is the creator of the ERC-7802 standard and, as far as I know, the only adopter). So the scope of application is very narrow.

So, you can include it in Compose, maybe someone finds a use case to ERC-7802 (e.g. resigning to decentralization), or maybe adoption grows (I doubt it) but I do not think it covers the requirements of decentralized+interoperability. In fact, possibly interoperability is now creating quite a few use cases / workflows that does not have an standard yet (e.g. all the chain abstraction umbrella). I would not expect to cover interoperability necessities with just ERC-7802 or just only one standard. We already passed this (centralized) stage and many new use cases have arisen (maybe good stuff for Compose).

[pellyadolfo]

I would state the problem in this way:

Use case: As a token operator I would like to be able to move liquidity of my token from network A to network B. In order to keep my reputation, I would also expect that the protocol that makes this operation guarantees to the retail investor that I cannot modify the total supply in the operation. I also would analize/discuss if there is any way to prevent creating an arbitrage opportunity with the operation so the token operator cannot benefit himself from moving tokens between networks (not sure about it).

Resolution: This requires building on top of the existing interop protocols. Hopefully the operator should be able to plug the interoperability protocol that he prefers. Some interface working as adapter pattern should abstract the operation to decouple from the interop protocols, so the protocol chosen by the operator plugs seamlessly into the system with this interface.

In my opinion this basic mechanism is the only one that could build trust for retail investors. Everything else is hidden and opaque. This is e.g. what Axelar's Interchain Token Service does but their trust model with their network and validators has been already improved by other providers. Ideally should be provider agnostic.

[pellyadolfo]

Summing-up: I think an ERC-2535 -based ERC standard, similar to these frameworks (=fix UX), decentralized by design (=fix scams) and deployed in the chains as composable facets (=ready to go) would be a starting point for many multichain projects (e.g. and many others) as ERC-20 is (was) for single chain projects and would bring the retail investors and blockchain industry back.

[mudgen]

Awesome, I appreciate it. I hope that ERC-2535 is leveraged for this purpose.

[farismln]

hey @mudgen can we pin/add this about the Compose design philosophy somewhere in the documentation?

IDK if this discussion is the best place for this but actually I really want to contribute to implementing EIP standard but I always held back by what should and should not be added into the implementation. that's why I only do some small fix or reviewing others PR.
but those documentation seems great for others who really wants to start contributing, so they would implement it on the right path and what Compose really trying to achieve.

[mudgen]

@farismln I really appreciate your help and I have been happy with your contributions to the project and want to work with you a lot more. You are absolutely right about this documentation. I am going to be working on organizing the documentation and improving it a lot more.

[mudgen]

@farismln Checkout the new documentation: https://compose.diamonds/docs/contribution/design/

[farismln]

hey @mudgen thanks. I'll check it out