ERC-223 in the Orbit of Ethereum Pectra

Introduction 

Pectra update is coming to Ethereum very soon. The update package includes improved steaking design for validators, improved scaling for L2 networks and a very interesting EOA EIP-7702 Account Abstraction mechanism for users, which endows user addresses with smart contract functionality. 

There is a view in the community that EIP-7702 will make some token standards that solve ERC20 design problems irrelevant. In particular, it is argued that ERC-223 and its communication model could easily be replaced by contract functionality after EIP-7702 is implemented. To confirm or refute this opinion, let us analyze the possible impact of EIP-7702 on token launches in general and on ERC-223 in particular. 

Possibilities of EIP- 7702

Account abstraction is not exactly a novelty, the ERC-4337 (formerly EIP-4337) standard was already adopted in 2023. However, ERC-4337 did not allow existing accounts to be upgraded to smart contract functionality, EIP-7202 removes this restriction.

To run EIP-7702, users sign the converted message using an EOA private key. The signature content includes “Chain ID”, “Contract address to transformed” and “EOA Nonce value”.

The developers emphasize the following opportunities:

• Different ways for users to authorize and sign transactions, from the EOA private key stored in the device to the use of email or biometrics.

• Mechanisms for restoring access to funds are possible. If a mnemonic or familiar authorization method is lost, assets can be transferred to a new account using the recovery mechanism built into the smart contract functionality.

• Multiple transactions can be bundled together and executed together in a single transaction. This is an aspect that many developers are hoping to address the problem of costliness when two transactions are required: approval and exchange/depository.  

• The contract can detail and expand delegation to third parties and more flexibly customize restrictions.

• It is possible for third parties to pay for gas or accept any other tokens to pay for gas.

And any other functionality available to smart contracts based on EVM blockchains can be realized.

Implicit problems of EIP-7702

• Expensive transactions. Complex smart contract functions are relatively expensive on Ethereum. Plus the EIP-7623 included in Pectra increases the cost of these calls. So what is truly acceptable to users would be to use EIP-7702 on L2 networks.

• The security of the private key or mnemonic phrase of an EOA is still a bottleneck. Even if a user's EOA becomes a multisignature, he still has to store his private key or mnemonic phrase securely. Theft of EOA authorization data will nullify all the benefits of multi-signature.

• The EOA account storage will not be formatted automatically when a conversion is canceled or converted to a new contract if the data is implicitly deleted. A clogged vault will increase fees and could theoretically cause transaction execution failures of the newly assigned contract.

• The process of converting an EOA to a smart contract does not include initialization. Since the contract is not deployed as usual by a Factory contract that performs initialization, there is a potential opportunity for an attacker to preempt the user by copying the user's conversion signature and gain control of the final account with smart contract functionality.

• Security of using third-party add-ons. For the vast majority of users, it is unrealistic not only to write their own smart contract, but also to check a verified contract for security, which makes it necessary to trust the provider of such modules. It is worth recalling the problem of the ERC-777 standard, which also required the connection of a third-party smart contract to expand functionality. These incidents led to a warning not to use ERC-777. 

The authors of EIP-7702 explicitly state that any potential problems should be addressed by the vendor of the smart contract implementation being used: “An improperly implemented delegate can allow an attacker to gain almost complete control of the signer's EOA.

Interaction of ERC-223 and EIP-7702

There are two original token standards capable of understanding whether the target contract supports working with these tokens and cancel the transfer if it does not.

The NFT ERC-721 standard, run safeTransferFrom, checks if the target contract contains an IERC721Receiver, which implies that it knows how to handle ERC-721 tokens. If you are writing a contract that should receive ERC-721, you need to enable this interface. If the return value shows that the contract does not have the IERC721Receiver interface, the translation will be canceled.

The ERC-223 standard using the library address module is able to determine the target account type and then find out if the target contract contains an IERC223Recipient, and if not, the token transfer will be canceled. 

With these communication mechanisms, both ERC-721 and ERC-223 solve the main design problem of ERC-20, namely the loss of funds in case of direct sending to smart contracts. It is worth noting that ERC-223 is the first standard to become a reliable alternative to ERC-20, which is clear even from the ERC sequence number. ERC-721 and other standards, realizing their communication models, were based on the experience and ideas of ERC-223, so it makes no sense to consider ERC-677, ERC-777, ERC-827, ERC-995, ERC-1003 and others within the framework of this analysis separately.

As you can see from the EIP-7702 overview above, Account Abstraction does nothing new that any other existing smart contract can't. Therefore, deploying EIP-7702 in a future Ethereum update would neither alter the widely used ERC-20 token standard nor resolve any of its inherent design flaws. 

The prospect of EIP-7702 being cost-effective by combining approval and spend transactions into a single packet is also questionable. As with two transactions, the number of function calls and fees will go nowhere. With the application of the intermediate contract assigned by the EOA, the number of calls will only increase, as will the fees. ERC-223 is originally designed to perform the transfer in one transaction, moreover it is possible to transfer both token and native coin in one call. 

But security is the worst of all. Besides ERC-20 design, saving and using problematic features in the code, we have to trust third-party suppliers of smart contract modules and as history shows loss of funds from unintentional or malicious actions is bound to happen. Sent tokens are in no way immune to being stuck in smart contracts. Of course, you can take the communication model from ERC-223 and integrate it into the smart contract functionality, but this will do nothing but complicate the logic and make the transaction more expensive. In addition, target contracts, such as Router trading DApps, must also contain a module that responds to requests.

ERC-223 has out-of-the-box functionality of communication with target contracts and rollback of transfer in case of non-compliance with the standard of the target contract. 

Conclusion

The analysis clearly shows that EIP-7702 not only fails to affect the relevance of ERC-223, but makes it more relevant than ever. Against the backdrop of increasing complexity of logic via Account Abstraction, ERC-223 is more secure and economical.

Of course, EIP-7702 is, in a global sense, a breakthrough in extending the functionality of EOAs. Embedding ERC-223 in this chain will only contribute to the security of the DApps under development.

Regarding the ideological reasons for this analysis, we can note the following: since the financial industry is always overheated with promises and expectations, one should be fully able to analyze information, and being critical of the background and the words of experts, especially if the Influencer is a maximalist from the opposing camp. 

- - -

Note: This analysis is entirely the author's vision. It is not a call to action or investment advice. 
This article is for informational purposes only and does not constitute financial advice. Investing involves risk, and you should consult a qualified financial advisor before making any investment decisions. Original reporting sources are credited whenever appropriate and as required.