Understanding EIP-7702’s Impact on Our Contracts and Mitigating Security Risks

Introduction

The Ethereum ecosystem is evolving rapidly, and the proposed EIP-7702 introduces a groundbreaking change: allowing Externally Owned Accounts (EOAs) to act as smart contracts by setting delegation designations. While this proposal improves the flexibility for EOAs, it also raises questions about how existing contracts interact with these hybrid accounts. In this article, we explain how EIP-7702 impacts our protocol’s security assumptions and why we believe the risks are manageable.

Background: Key Changes Introduced by EIP-7702

EIP-7702 allows EOAs to set their code to a delegation designator (0xef0100 || address), enabling them to delegate code execution to a predefined contract. This blurs the line between EOAs and contracts, particularly affecting checks that rely on tx.origin or msg.sender.

For example:

• tx.origin is no longer guaranteed to be a "pure" EOA (it could be an EOA with delegated code).
• Contracts can now masquerade as EOAs in certain contexts.

Impact on Our Protocol

Our protocol uses tx.origin checks and reentrancy guards in critical areas. Below, we analyze the implications of EIP-7702 on these components.

A. Reentrancy in lzSend

We identified 5 instances of cross-chain interactions via lzSend, which could theoretically be vulnerable to reentrancy. In particular,

_lzSend(
    ...,
    ...,
    msg.sender == tx.origin ? msg.sender : payable(owner()), // To avoid reentrancy
    ...,
    ...,
    ...,
);

This ternary expression specifies the refund address, which is designed to send excess gas fees back to intentionally:

1. The direct EOA caller (tx.origin) when interacting normally OR
2. The contract owner when called via a contract (to prevent reentrancy)

EIP-7702 breaks this security assumption because the refund call in LayerZero’s https://github.com/LayerZero-Labs/LayerZero-v1/blob/a1fb11a3b9c0ac449291816e71eacede4e36613e/contracts/UltraLightNode.sol#L226

_refundAddress.call{value: amount}("")

now becomes reentrant when an attacker deploys and sets their EOA’s code to delegate to a malicious contract, which with excess gas, the cross-chain call will trigger the EOA’s fallback function and re-enter during the refund.

However, paying closer look reveals that mitigations are already in place:

1. 4/5 instances follow the checks-effects-interactions pattern, making reentrancy attacks ineffective.

• Example: ChessScheduleRelayer
• The check require(startWeek > lastWeek, "Not a new week") and effect lastWeek = startWeek both take place ahead of the _lzSend interaction with external contracts, thereby ensuring that repeated calls within the same week fail, neutralizing this risk.

2. 1 instance in VotingEscrowV4 triggers a callback after lzSend, but it is protected by a nonReentrant modifier.

B. assertNotContract in VotingEscrow

The assertNotContract modifier checks tx.origin == msg.sender to prevent smart contracts from vote-locking CHESS, which potentially leads to re-tokenization (allowing smart contracts to create new transferable token representation out of the locked positions). Despite the fact that re-tokenization does not pose a direct threat to user assets, the tx.origin restriction helps to preserve the non-transferability of veCHESS — a core mechanism ensuring that the governance power remains tied to locked tokens until their unlock time. Under EIP-7702, however, EOAs with delegation code can bypass this check, potentially allowing their delegated code to interact with VotingEscrow.

Why Re-tokenization via Delegated EOAs is Acceptable:

• Not Permissionless:

Retokenization via delegated EOAs is neither trustless nor permissionless — it requires the EOA’s private key, meaning only the original owner can initiate or modify it. Unlike a permissionless smart contract, delegation is opt-in and self-custodial, analogous to upgrading a smart contract wallet without on-chain governance at all. User interacting with the delegated EOAs therefore will bear tremendous trust risk, as the EOA owner can revoke or alter delegation at will.

• Not Scalable:

Re-tokenization via delegated EOAs is not scalable for larger-scale operations. The primary purpose of re-tokenization is to create general composability and liquidity for an intentionally illiquid asset like veCHESS. However, even if a multi-sig scheme manages the EOA’s private key, the delegation mechanism of EOA addresses remains rigid and non-composable. Unlike a collection of non-upgradeable/upgradeable smart contracts with DAO supervision (e.g., Uniswap, Aave, Lido, Tranchess…), a multi-sig-controlled EOA still lacks a programmatic governance layer, retaining absolute, unilateral authority over the delegation. This makes it incompatible with the composable primitives of the DeFi ecosystem's liquidity layer, such as AMMs and lending markets.

Conclusion

EIP-7702 represents a significant step toward account abstraction, but it requires re-evaluating assumptions about EOAs. For our protocol:

• Existing safeguards and logical checks mitigate reentrancy risks.
• assertNotContract bypasses are low-risk and user-driven.
• EIP-7702 introduces no critical vulnerabilities in its current form.

We remain committed to security and will continue to adapt to Ethereum’s evolving landscape. For questions or feedback, reach out to us on GitHub or Twitter.