EIP-3074

Better, Safer User Experience

EIP-3074 allows EOAs to delegate control to specified contracts, thereby gaining rich execution capabilities similar to contracts. Before EIP-3074, an EOA could only perform one operation per transaction, such as approving an ERC20 token or making a swap on Uniswap. Post-EIP-3074, an EOA can complete multiple operations in a single transaction, enabling previously unimaginable use cases. In essence, EIP-3074 significantly improves the user experience and reshapes familiar authorization methods while enhancing security.

Moreover, with EIP-3074, EOAs no longer need to send transactions on-chain themselves, thus eliminating the need to first acquire ETH to pay for transaction fees.

Invoker Contracts

Contracts that can gain control of EOAs are called Invoker contracts. Not just any contract can gain control; the EOA must sign with its private key, specifying which Invoker contract and which operations it authorizes the Invoker to perform.

The process typically involves:

Alice signs with her EOA private key, specifying the Invoker contract and authorized operations.

Alice submits the signed content and signature to a Relayer.

The Relayer submits the transaction on-chain to the Invoker contract.

The Invoker verifies the signature and, upon validation, executes the operations as Alice’s EOA, such as approving USDC, swapping assets on Uniswap, and using some USDC to pay the Relayer as a fee.

Note: The Relayer is optional; Alice can submit the signed content and signature on-chain herself.

Avoiding Replay Attacks

The Invoker executes operations as if it has limited control of Alice’s EOA. However, the EOA’s nonce does not increase after execution, meaning the same signature could potentially be reused as long as the EOA’s nonce remains unchanged. Therefore, the Invoker must implement its nonce mechanism to prevent replay attacks.

Learn More

For a detailed introduction to the workings of EIP-3074, please refer to:https://medium.com/taipei-ethereum-meetup/eip3074-%E7%B0%A1%E4%BB%8B-2a880b918234

Applications of EIP-3074

Batchcall

Batchcall allows users to combine multiple transactions into one, saving the process of multiple authorization signatures and some gas costs. Note that this requires DApps to support Batchcall functionality, such as the currently promoted EIP-5792. Without such support, DApps will prompt a separate transaction for each operation, treating the user as a regular EOA.

For more information on EIP-5792, please refer to: EIP-5792.

Session Key

Users can delegate operations to a third party under specific conditions using a session key. In the example below, the delegate key represents the authorized third party, while the access policy defines the operational constraints, such as limiting actions to Uniswap, capping transfers at 1 ETH per day, or setting an authorization expiration date. These conditions are designed and checked within the Invoker contract. Once the checks pass, the third party can perform operations as the user’s EOA.

For instance, a Telegram Bot could be granted specific permissions to execute operations on behalf of the user’s EOA.

Native ETH Permit

If the conditions are met (i.e., the permit signature is valid), operations can be executed as the authorizing EOA, enabling native ETH Permit functionality.

Limit Order

Users can set limit order conditions, which, once met, allow operations to be executed as the user’s EOA. This includes approving relevant digital assets for a DEX and swapping assets on the DEX. Compared to the limit order functionality provided by DEXs themselves, users do not need to pre-approve assets for the DEX.

For example, when Alice completes a limit order, the approval is executed simultaneously, eliminating the need for prior approval.

By designing the conditions more generally, an Intent contract can be created: as long as the specified conditions are met, anyone can execute the intent on behalf of the user’s EOA.

Social Recovery

If a user loses their EOA private key, they can use the previously signed EIP-3074 authorization, along with signatures from authorized parties (e.g., Husband and Trust Agent), to transfer all assets from the EOA. This recovers the (transferable) assets, not the account control. Once the EOA private key is lost, the EOA cannot be used again.

Improving Asset Authorization Methods

EIP-3074 has the potential to improve or even replace current approve/permit methods. DApps currently operate under the assumption that users are EOAs: users must pre-approve a sufficiently large amount of assets to the DApp contract to avoid staying online constantly and repeatedly approving transactions. This significantly improves the user experience.

For example, conditional applications such as limit orders or DCA require users to pre-approve a large amount of assets so the DApp can execute operations when conditions are met, potentially multiple times.

However, this requires users to trust the DApp or avoid approving fake DApps, and they must be able to remove approvals in real-time.

Recent permit models like EIP-2612 or the non-native Permit2 aim to improve the approve model’s user experience and security. Users do not need to approve large amounts of assets for each DApp contract; instead, they can authorize DApps to withdraw a specified amount of assets within a specified time by signing once. This greatly reduces the attack surface and enhances the user experience.

△ Users only need to sign off-chain, and they can specify the asset amount and validity period, providing a better user experience and security than approve.

However, in reality, not just approve, the permit mode is still frequently exploited as a scam method. Victims mistakenly sign permits they believe are for DApp use but are actually giving authorization to attackers.

△ When users sign a permit, they can only see who they are authorizing but do not know what operations will be performed in conjunction with it.

Note: The current permit design is incompatible with DApps requiring repetitive operations, such as DCA or other periodic payment applications. This is because the permit has an anti-replay mechanism, so once a transaction is completed, the same permit cannot be used again. Essentially, users need to pre-sign permits for each future repetitive operation.

Learn More:

To understand more about incidents where the permit mode has been exploited as a scam method, please copy the following links into your browser for more information:

• Link 1

• Link 2

• Link 3

However, EIP-3074 brings a chance for change: when DApp developers realize that EOA can perform various complex operations through Invoker, the design of DApp interactions will no longer need to sacrifice security for better user experience, such as “users approving a large amount of assets in advance” or “users signing a permit message to authorize withdrawals.”

Instead, users will tie the DApp operation with the approve action, executing them atomically through Invoker: either both the approve and the DApp operation succeed together or fail together. There is no possibility of the approve action succeeding alone, so users can be sure that this approve action is specifically for the current operation.

Moreover, users authorize using off-chain signatures, so the user experience is the same as with permit! This means that DApps will no longer need the permit mode! In the future, wallets can directly block or more strictly scrutinize permit signature requests without worrying about preventing users from accessing certain DApps (but rather being exploited by scams).

△ Users will no longer just authorize a certain address but also specify what actions can be taken, and they can even see simulated execution results.

Note: This does not mean scams can be completely prevented! Users can still be tricked into scam websites, and scam websites can still craft approve or transfer operations for users to sign. However, at this point, users can at least see what operations the signature is authorizing. Wallets can even simulate and display execution results, showing users clearly who will lose money and who will gain money. Compared to permits where users cannot know the operations or execution results, users now have more information to decide whether to authorize. While not a perfect solution, it is still a significant improvement over the current situation.

How Wallets Handle EOA Nonce

Currently, the design of EIP-3074 includes the EOA nonce value in the signature content. Therefore, as soon as the EOA submits a transaction on-chain that alters the nonce value, all existing EIP-3074 authorizations become invalid.

If a user authorizes others to operate their EOA on their behalf, such as through the Session Key or Social Recovery methods mentioned above, the EOA’s nonce must remain unchanged. Otherwise, all authorizations must be re-signed and handed over to the trustee, which significantly impacts both user experience and the robustness of the mechanism.

If the user is authorizing themselves to operate, then there is no need to avoid changing the EOA nonce. EIP-3074 signatures, like transactions, are expected to be executed within a certain period. However, wallets must manage EIP-3074 transactions for the EOA: if there is an EIP-3074 signature waiting to be on-chain, any EOA transactions must wait.

Note: The Invoker contract itself should maintain a separate nonce mechanism, so each signature must be renewed regardless of changes to the EOA nonce.

Session Key and Social Recovery are likely to be widely adopted only after EIP-3074 modifies the rules to remove the EOA nonce from the signature content. Therefore, wallets should focus on the scenario where “users authorize themselves to operate” and treat EIP-3074 signatures as they would transactions, avoiding concerns about EOA transactions altering the nonce.

However, if users want to submit their EIP-3074 signature on-chain themselves, there are two drawbacks:

1. Users need to sign twice: once for the EIP-3074 signature and once for the on-chain transaction signature.

2. Since the on-chain transaction will increment the EOA nonce before execution, the EIP-3074 signature’s EOA nonce must be pre-incremented to match the nonce change caused by the on-chain transaction.

△ Because the on-chain transaction increments the EOA nonce, EIP-3074 signature verification will fail if the nonces do not match.

△ Users need to pre-increment the EOA nonce in the EIP-3074 signature to pass verification successfully.

By understanding these nuances, wallet providers can better manage EOA nonce handling, ensuring a smoother and more secure user experience with EIP-3074 authorizations.

Summary and highlights

• EIP-3074 grants EOAs (Externally Owned Accounts) the same rich execution capabilities as contracts, unlocking numerous new application scenarios.
• This not only significantly enhances the user experience but also transforms the current authorization methods, making them safer without compromising on usability.
• Moreover, EIP-3074 involves simple signatures, so users don’t necessarily have to execute these signatures on-chain themselves, eliminating the need to gather ETH to pay for transaction fees.
• The uses of EIP-3074 include Batch Call, Session Key, Native ETH Permit, Limit Order, and Social Recovery. Many of these are originally impossible to achieve with EOA, and some, such as Limit Order, require pre-authorization and other less secure methods to be used.
• These were previously impossible for EOAs. For instance, using Limit Order required less secure methods like pre-authorization.
• EIP-3074 will also change the current authorization methods. The approve method directly authorizes a specified address to withdraw unlimited digital assets indefinitely, requiring the user’s EOA to send a transaction to execute the approval, resulting in poor user experience and security. The permit method only requires the user’s signature, and each signature specifies the asset amount and validity period, greatly improving the user experience and security compared to approve.
• However, the permit method is still frequently exploited in scams. When signing, users can only see the address, asset amount, and validity period they are authorizing, but not the purpose of the authorization. The purpose would be defined in another signature (or transaction). A legitimate DApp would require the user to sign both the permit and the purpose, but these are two separate signatures. Hence, when requested to sign a permit, users and wallets cannot determine the permit’s intended use.
• With EIP-3074, users (1) do not need to approve a large amount of assets to the DApp in advance, but only approve when there is an operation, and the effect is the same as permit; (2) just sign and do not need to worry about collecting ETH to pay the procedure The fee is the same as permit; (3) Each approve is bound to the specified operation and signed together. The user can clearly know “what the approve is used for” this time. This will be safer than permit!
• It is hoped that EIP-3074 will successfully replace the current approve and permit methods, providing users with a more secure authorization method.

Disclaimer：

1. This article is reprinted from [ imToken Labs]. All copyrights belong to the original author [Nic]. If there are objections to this reprint, please contact the Gate Learn team, and they will handle it promptly.
2. Liability Disclaimer: The views and opinions expressed in this article are solely those of the author and do not constitute any investment advice.
3. Translations of the article into other languages are done by the Gate Learn team. Unless mentioned, copying, distributing, or plagiarizing the translated articles is prohibited.