[Past] AllERCDevs S2E5 Agenda 2300UTC Tuesday (APEC friendly time)

[xinbenlv]

Agenda

• EIP-5792 Wallet Function Calls API by @jxom, lead dev of wevm.dev, viem.sh (https://twitter.com/_jxom) 15min (Q&A included)
• [Briefing] EIP-7713 Box type for EIP-712 messages by @frangio
• EIP-5269 (ERC Discovery Interface) in context of 1271-712 by @xinbenlv and @Vectorized

Peer Reviewer Invited

• Bumblefudge

Meeting Links

https://meet.google.com/hvy-rqbv-fnu?authuser=0

Recordings and Notes

• Notes and Recording: https://app.fireflies.ai/view/AllERCDevs-S2E5::FdT8TCEsH5siNzKx

In #AllERCDevs S2E5, we mainly discussed ERC-5792, ERC-7713, and the related topics such as ERC-5269, ERC-165. Jake Moxey (@jxom), Lukas Rosario (@0xlsr), and Francisco Giordano (@frangio) led the ERC-5792 discussion, with feedback from Vectorized (@optimizoor), William Entriken (@fulldecent) , and Victor Zhou (@ZainanZhou).

1. Jake Moxey (@_jxom) introduced himself, highlighting his work at WebM on TypeScript tooling and libraries for Ethereum, including notable libraries like viem.sh, wagmi.sh, and abitype.dev. Jake discussed ERC-5792, the wallet call API. This ERC facilitates sending calls between a dApp and a wallet with capabilities such as batch calling, atomic batching (sending multiple calls in a single transaction), sponsored calls (wallets covering gas fees), and session keys (allowing wallets to perform calls on behalf of the user without explicit approval).

Jake explained the limitations of eth_sendTransactions, which is primarily built for EOAs and lacks efficient methods for sending multiple transactions. ERC-5792 addresses these issues by introducing four new RPC methods: sendCalls, getCallStatus, showCallStatus, and getCapabilities. These methods enable a more efficient and flexible approach to handling transactions, especially for smart contract accounts.
He demonstrated how sendCalls works, allowing DApps to send a batch of calls without needing to know the type of account (smart contract or externally owned). This abstraction simplifies application development, focusing on functionality rather than account complexities. Jake detailed the end-to-end process of how sendCalls operates, including handling user operations for smart contract accounts and managing transactions for externally owned accounts.

Additionally, Jake discussed the concept of wallet capabilities, which allows DApps to discover and utilize specific features supported by wallets, such as atomic batching and Paymaster services. He also touched on future considerations for ERC-5792, including more intuitive multi-chain behavior and additional capability ARCs like ERC-7677 (Paymaster) and ERC-7715 (permissions). Jake highlighted the support for ERC-5792 from various wallets and tooling, including Coinbase Smart Wallet, Safe Wallet, and Rivet.

2. Francisco Giordano (@frangio_) presented ERC-7713, which introduces a new "box type" to address limitations in the current ERC-712 signatures. The "box type" allows for arbitrary extensible data in a structured manner without type erasure, making the data more understandable for end users. Francisco cited ERC-7683 (cross-chain intents) as an example where this pattern could be beneficial. He highlighted that the current approach results in unreadable hexadecimal strings in user interfaces, which users often ignore, potentially leading to security risks.
   The proposed "box type" would standardize the outer structure while allowing the contents to remain implementation-specific and easily interpretable by users. Francisco also mentioned its application in replay protection for ERC-1271, explaining how it simplifies the encoding and maintains constant size, thus enhancing the expressive power of ERC-712 signatures.

3. The discussion moved to ERC-5269, proposed by Zainan Victor Zhou, aiming to improve the detection and declaration of behaviors in contracts. Vectorized highlighted the limitations of ERC-165 in detecting specific contract functionalities and supported the idea of using ERC-5269 for more flexibility. William Entriken suggested using URNs and hashes for more efficient implementation, while acknowledging the challenge of competing with established standards like ERC-165.

We appreciated @ZainanZhou, @frangio_, @optimizoor, @fulldecent, @0xlsr and @_jxom for their valuable insights and participation.
Appreciate our volunteer @alohalily668 for facilitating the session, and @ethmagicians, @ethcatherders, @EIPfun, and @Namefi_io for supporting #AllERCDevs. Appreciate our volunteer @sunnyguoyuan for facilitating the session and taking the notes too.

A reminder to the community: AllERCDevs is actively recruiting volunteers for various roles, including meeting hosts and tech-writers, and is calling for future presenters and peer reviewers. If you're building anything related to interoperability with EVM smart contracts, such as dApps, CEX, DEX, wallets, DeFi, or explorers, your contribution and involvement would be highly valued.

For those interested in joining the conversation, contributing to the standardization, or providing peer review, don't hesitate to reach out directly through DMs or join the TG group: https://t.me/+j4px1GisBSkzMDZh. For more details, see the agenda: https://github.com/ercref/AllERCDevs.

Tentative next agenda is open for sign-up.

Stay tuned for the next AllERCDevs meetup, promising to bring even more innovative discussions to the table. #AllERCDevs

End of Session Checklist