This educational project is dedicated to comprehensive training for the Spanish-speaking developer community on EIP-7702: Set Code for EOAs, with an emphasis on security, practical examples, and implementation best practices. We will introduce the new EIP-2718 transaction type (identified as 0x04), which allows Externally Owned Accounts (EOAs) to permanently set code for their own accounts. The project will offer a deep understanding of its technical operation, its complex security implications, and the transformative user experience (UX) improvement opportunities it enables, such as batching, transaction sponsorship, and privilege de-escalation. Through clear resources, code examples, and use case analysis, we will equip developers to integrate this EIP in a robust and reliable manner.

Our mission is to empower the Spanish-speaking developer community by providing them with the comprehensive knowledge, practical examples, and security best practices to securely understand, implement, and leverage EIP-7702. By facilitating the adoption of this standard, we seek to accelerate the integration of substantial improvements in the user experience (UX) of Ethereum decentralized applications, removing friction and promoting innovation. We will empower developers to build more efficient, secure, and user-friendly solutions that unify UX efforts and pave the way for the ultimate account abstraction, ensuring the compatibility and robustness of the Ethereum ecosystem using Celo's L2.

Although EIP-7702 introduces transformative features that promise to unlock significant user experience (UX) improvements for Externally Owned Accounts (EOA) on Ethereum, such as batching, transaction sponsoring, and privilege de-escalation, the lack of accessible educational resources, practical examples, and clear and secure guidelines represents a crucial barrier to widespread adoption, especially within the Spanish-speaking developer community.

Currently, developers face the challenge of correctly understanding and implementing the technical complexity and severe security implications of EIP-7702, which include:

• New Transaction Type and Code Delegation: The EIP introduces a new EIP-2718 transaction type (0x04) that allows EOAs to establish code using authorization tuples, writing a delegation flag (0xef0100 || address) that forces executing operations to use the targeted code. This involves a complex understanding of tuple verification, authority nonce increment, and managing specific gas costs.
• Critical Security Caveats: The authors have explicitly warned that "there is no secure way to provide this interface" directly to users, and that "a poorly implemented delegate can allow a malicious actor to take near-complete control of a signer's EOA". This requires developers to implement essential protections in secure delegate contracts, such as replay protection (via a delegate nonce) and transaction parameter validation (value, gas, target, calldata) to prevent malicious use.
• Initialization and Storage Challenges: The lack of initcode and atomic storage setting forces developers to mitigate front-running at initialization by verifying calldata with ecrecover. Additionally, Storage Management is critical to avoid collisions when migrating between delegated contracts, potentially using standards like ERC-7201.
• EVM Invariant Breakage: The EIP breaks key invariants, such as that the balance and nonce of an EOA only decrease/increase for transactions originated by it, and that tx.origin == msg.sender is always true in the top frame of execution. This impacts protections against atomic sandwich attacks and reentrancy.

This critical gap in knowledge and practical resources hinders innovation and secure adoption of EIP-7702, preventing decentralized applications from fully leveraging its potential for improved UX and secure compatibility with future account abstraction (ERC-4337).

EIP-7702 introduces a new EIP-2718 transaction type (type 0x04) that allows EOAs to establish code in their own accounts. This is achieved by attaching a list of authorization tuples to the transaction, where each tuple indicates the code a signer wishes to execute in the context of their EOA. For each valid tuple, a delegation flag (0xef0100 || address) is written to the authorizing account's code, forcing all executing operations (such as CALL, DELEGATECALL, STATICCALL) to load and execute the code pointed to by that address.
This solution, which our project will facilitate with detailed guides and secure code examples, enables three key UX improvements:

• Batching: Allows multiple operations from the same user in a single atomic transaction, such as approving and spending an ERC-20 token, reducing the need for multiple transactions.
  Sponsorship: Allows one account (X) to pay for a transaction on behalf of another (Y), facilitating models where applications subsidize their users' gas fees or implementing new business models. It also enables self-sponsorship by allowing tx.origin to establish code.

• Privilege de-escalation: Allows users to sign subkeys with specific, more restrictive permissions than global account access, such as spending only ERC-20 tokens, limiting daily spending, or interacting with a specific application.

To address the identified complexity and security concerns, our project will provide:

• Working examples and delegated contract templates that implement recommended security protections, such as replay protection and parameter validation.
• Step-by-step guides for handling front-running initialization and secure storage management.
• Clear explanations of broken EVM invariants and how developers should adapt their contracts to mitigate risks.

Just want it to build it as side gig

Global community of Spanish-speaking Ethereum developers.