Upgrade for EIP-7702 Compatibility (Pectra Upgrade)

Hello SKALE Community and Development Team,

I would like to share a proposal to evolve SKALE Network and keep it at the forefront of EVM technological advancements. With the Pectra upgrade on Ethereum, EIP-7702 introduces significant changes that could greatly benefit the SKALE ecosystem by enhancing user experience, improving interoperability, and unlocking new EOA-related functionalities.

Why is EIP-7702 Important for SKALE?

EIP-7702, included in the Pectra hard fork, introduces a new transaction type (0x04, SETCODETX_TYPE) that enables externally owned accounts (EOAs) to adopt smart contract functionalities through a delegation mechanism. Here are some key benefits for SKALE:

• Native Account Abstraction: EOAs will be able to perform advanced operations such as transaction batching, and social recovery, making SKALE dApps more accessible and user-friendly. SKALE projects can leverage sFUEL to implement free bundlers and paymasters, optimizing gas loads on network nodes.

• Compatibility with ERC-4337: EIP-7702 is designed to complement ERC-4337, enabling seamless integration with existing wallets (e.g., MetaMask, Safe) without requiring complex asset migrations.

• Cross-Chain Flexibility: Cross-chain authorizations (with chain_id=0) simplify multi-network interactions. For SKALE, a single signature could encompass operations across different SKALE chains (e.g., Europa and Nebula), eliminating the need for users to manually switch chains, thus improving the user experience.

• Enhanced User Experience: Features like limited sub-keys and simplified smart wallet management can attract more developers and users to SKALE. Integrating frameworks like Biconomy or Privy (which is Unity-compatible and offers a ready-to-use account abstraction SDK) would be a significant advantage.

Proposal

I propose that the SKALE team considers a protocol upgrade to ensure compatibility with EIP-7702. This would involve:

• Updating SKALE nodes to support the Pectra hard fork, including the new 0x04 transaction type.

• Adapting SKALE’s EVM to handle the delegation mechanism (storing the delegation designator and executing delegated code).

• Collaborating with wallet providers (e.g., Privy) and SDK like biconomy to ensure SKALE users can fully leverage EIP-7702 features.

• Providing documentation and developer support to facilitate the integration of these new features into SKALE dApps.

Benefits for the SKALE Ecosystem

• Competitiveness: By adopting EIP-7702, SKALE will remain aligned with Ethereum standards, strengthening its position as a high-performance layer-1 solution.

• Increased Adoption: Account abstraction features simplify onboarding for non-technical users, a key driver for mass adoption.

• Innovation: SKALE developers can build more complex and flexible dApps, leveraging capabilities like multichain transactions and modular authorizations.

I believe this upgrade could position SKALE as a leader in the post-Pectra Ethereum ecosystem. I’d love to hear your thoughts, suggestions, or any updates on the team’s plans regarding this topic. Thank you for your attention and commitment to innovation!

Drikkx
ForLootAndGlory Co-Founder

1 Like

Hey @Drikkx,

This is an excellent and forward-thinking proposal—bringing EIP-7702 to SKALE would be a huge step toward enhancing user experience and developer flexibility across the ecosystem.

The ability for EOAs to temporarily adopt smart contract functionality via delegation opens up a world of possibilities, and on SKALE, where gas fees are already zero, the potential is even greater. Developers could create incredibly smooth and intuitive user experiences without having to rely on custodial wallets or complex account management flows.

What’s even more exciting is how naturally this aligns with SKALE’s multi-chain architecture. With EIP-7702 supporting cross-chain authorizations, and considering that all SKALE chains have zero gas fees, it becomes much more feasible to build dApps that span multiple SKALE hubs (e.g., Europa, Nebula) without friction.

I have have to dig a bit further on the EIP-7702 but do you have any insight or ideas on how this could benefit a multi-chain ecosystem like SKALE Network?

Of course, as with any new contract mechanism, especially one that touches account permissions, there’s always a security component to consider. Smart contracts designed to drain assets or exploit delegations could be a risk, but since deployers need to get whitelisted to deploy on SKALE Chains the risk might be mitigated.
For low-risk, valueless interactions—such as gaming stats, achievements, or leaderboards—this functionality could be adopted immediately and with minimal concern.

I’m super excited to see this kind of innovation proposed for SKALE. It’s exactly the kind of move that can keep the network ahead of the curve and attract both developers and users looking for power and simplicity in one place.

Manuel Barbas

Hey @ManuelBarbas ,

I really appreciate the approach of Biconomy’s Mee framework. It’s already being utilized on other EVM layers, and I believe this is a key aspect that could bring tremendous value. Connecting SKALE hubs with reduced friction is fantastic, but enabling interchain interactions across all EVMs in the ecosystem is something truly exciting to explore. Applications on SKALE could be used from any other layer that implements Biconomy’s Mee or other frameworks compatible with EIP-7702.

Given that SKALE is gas-free and leverages BITE, Europa could become a DeFi hub with minimal price impact and bridge fees. A game on Nebula, for instance, could sell in-game assets on any layer and link player interactions back to Nebula. This would showcase SKALE’s technology to other EVM users, highlighting its strengths and potential.

Hey @Drikkx

I think this is a fantastic request and I fully agree!
I think one question in this case that is worth discussing is how something like EIP-7702 would work regarding the smart contract component. Per @ManuelBarbas’s comment above; I think on a SKALE Chain with the permission layer active, there would probably need to be either:

a. Some sort of provider that has the contract deployed
b. For those who want to self-deploy, require them to pay or maybe burn SKL

Overall – I don’t think it needs to be overcomplicated BUT the reality is that contracts consume state and since state is functionally paid for by developers it would need to be considered during integration on SKALE Chains.

Otherwise, I think the actual concept of EIP-7702 is very powerful (despite being very unexplored)!