# L2 Interop Working Group - Call #7 **April 16th, 2025** - [Recording](https://www.youtube.com/watch?v=PKLMRXjizbs) - [Calendar invite for future calls](https://docs.google.com/forms/d/e/1FAIpQLSfMFEJmyVgjLuiipgxprEkiQXwwK3F_PfGbWvU8ZmV6e_ka0A/viewform) ### [Agenda](https://github.com/ethereum/pm/issues/1404) 1. [ERC-7786](https://eips.ethereum.org/EIPS/eip-7786): message passing discussion ## Call Notes *condensed notes below – watch the recording (above) for full discussion* ### TL;DR - Message passing is a key primitive for solving fragmentation (e.g. crosschain assets, allow apps on different chains to communicate, etc) - 7786: designed to solve fragmentation by unifying many message passing formats under a single API (lets apps use different message passing standards & still talk to each other) - 7786 is designed to be as minimal and lightweight as possible so that other applications / modules can be plugged in around it - Once you have the consistent API for sending messages, applications and all kinds of middleware can be built in parallel and evolve rapidly - Similar to agreeing on a format for mailing addresses, but you can then decide if you want to use UPS, FedEx, or DHL for delivery - Important that the protocol is neutral & avoids vendor lock-in, and to avoid the ecosystem being dependent on a single entity - Two main "customers" of 7786: (1) application developers, and (2) protocol developers - for application developers: easier to go multi-chain if they can use a single API to connect multiple messaging protocols across different chains (e.g. receiving a message from Chain A uses Protocol X, but receiving a message from Chain B uses Protocol Y). Apps can focus on their smart contract code, and the interop part is modular. - for protocol developers: allows for more innovation and modularity in different parts of the interop stack (e.g. someone creating a novel verification mechanism), and then push that innovation to existing apps without making those apps changing their whole interface. Applications would have the ability in the future to switch to more secure verification mechanisms (eg as ZK advances) without having to completely rework their contracts. Goal is to support continued innovation around verification mechanisms. - But why would any messaging protocol adopt this? Plan is to develop adapters so that 7786 can be easily adapted to work with any messaging protocol, even without a direct integration from the protocol itself. - Currently seeking community feedback on 7786 and open to suggestions for improvements - What is the "success criteria" for 7786 (eg 18 months down the road, how do we measure success): - ship the adapters to support different messaging protocols in the next 3-6 months so that apps can start using them - new interop protocols and applications are coming out using the 7786 interface - enabling more OpenZeppelin contracts to embed crosschain messaging