EIP-3074

Better and safer use experience

EIP-3074 allows EOA (Externally Owned Accounts) to transfer control to a specified contract, thereby obtaining the same rich execution capabilities as the contract. Before EIP-3074, an EOA could only perform one operation per transaction, such as approving ERC20 or swapping on Uniswap. After EIP-3074, an EOA can perform multiple operations at once, or even accomplish previously unimaginable tasks. Simply put, EIP-3074 greatly enhances the user experience, and the familiar token authorization method will be reshaped, increasing security without changing the user experience.

Moreover, through EIP-3074, EOA no longer needs to send transactions to the chain by itself, eliminating the trouble of having to raise ETH to pay transaction fees.

Invoker Contract

The contract that can obtain the control of EOA is called the Invoker contract. Of course, not just any contract can gain control of the EOA: the EOA must sign with a private key, and the content of the signature will clearly specify which Invoker contract it is and what operations the Invoker is allowed to perform.

EOA signature content will clearly specify which Invoker contract (invoker address) and authorize the operations of that Invoker contract (commit)

The actual execution process will probably look like this:

1. Alice signs with her EOA private key and then gives the signature content and signature to the Relayer
2. Relayer brings the chain to Invoker contract execution
3. The Invoker verifies the signature. After passing the verification, it can perform operations as an EOA, such as approving USDC, then going to Uniswap to exchange, and finally transferring some USDC to the Relayer as a handling fee.

Note 1: Relayer is not necessary. Alice can also bring her own signature content and seal to the chain.

After the Invoker verifies the signature and starts executing the operation, it will be executed as Alice EOA, which is like obtaining (limited) control of the EOA.

However, it should be noted that the nonce value of the EOA will not be increased after execution, so the same signature may be reused (as long as the EOA nonce remains unchanged), so the Invoker needs to implement its own nonce mechanism to avoid replay.

If the Invoker contract is not Replay-proof, the same authorization can be executed all the time.

For an introduction to the actual operating mechanism of EIP-3074, please refer to: Introduction to EIP3074

Application

Batchcall

Allow users to merge the execution of several transactions into one, saving the process of multiple authorized signatures and some Gas costs.

Note: This will require the dApp to also support the Batchcall function, such as EIP-5792, which is currently being pushed by the community. Otherwise, the dApp will only prompt the user to sign once for each operation if it treats the user as a normal EOA.

Session Key

Users can also allow a third party to act on their behalf under certain conditions. The delegate key in the diagram below is the authorized third party; the access policy is the execution restriction, such as limiting it to only operate Uniswap, transfer a maximum of 1 ETH per day, authorization validity period, etc. These conditions are designed and checked within the Invoker contract. As long as the check is passed, the third party can execute operations as a user’s EOA.

Telegram Bot can be given specific permissions to perform operations on behalf of the user’s EOA

Native ETH Permit

As long as the conditions are met (that is, the Permit signature is legal), the ETH transfer can be performed as the authorizer EOA, achieving the effect of the native ETH Permit.

Limit Order

The user fills in the limit order conditions, and when the conditions are met, it can be executed as the user EOA, including approving tokens to DEX, going to DEX for redemption, etc. Compared with the Limit Order provided by DEX itself, users do not need to send transactions to DEX for approval in advance.

When Alice completes an order, she will execute an approval at the same time, eliminating the need for prior approval.

If the condition is designed to be more general, it will become like an Intent contract: as long as the conditions specified by the user are met, anyone can execute the intent in the name of their EOA.

As long as the Intent condition is met, anyone can initiate execution in the name of the user’s EOA

Social Recovery

When the user loses the EOA private key, she (Alice) can use the EIP-3074 authorization she signed, along with the signatures of her authorized person (Husband and Trust Agent) to transfer all assets of the EOA. In reality, what is recovered are the (transferable) assets, not the account control. After the EOA private key is lost, the EOA can no longer be used.

When the user loses the EOA private key, other authorized persons can sign and authorize the transfer of EOA assets.

Impact of EIP-3074

Improving token authorization methods, and potentially replacing approve/permit?

Currently, dApps are designed under the assumption that the user is an EOA: the user must “pre-approve” and “approve a sufficient amount of money” for the dApp contract. This means users do not need to stay online all the time, wait for the dApp to execute, or constantly re-approve, greatly improving the user experience. For condition-triggered applications such as limit orders or DCA, users may not be online when conditions are met, so they need to pre-approve a large enough amount of money for the dApp contract to execute, and it may be a repetitive process.

The user must approve a large enough amount for the dApp in advance so that the dApp can operate with its money.

But it is also necessary to trust the dApp or avoid approving the fake dApp, and to be able to remove the approval immediately

The permit modes that appeared later, such as the token-native EIP-2612 or the non-native Permit2, are all to improve the use experience and security of the approve mode: users no longer need to approve large amount of money to each dApp contract (and each token has to be approved once). Instead, the user only needs to “sign a name” to authorize the dApp contract to “withdraw the specified amount” within the “specified time”. This not only greatly reduces the attack surface, but also greatly enhances the user experience.

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

But in fact, not only approve, the permit mode has been used as a scam attack method frequently (1,2,3): victims mistakenly signed what they thought was a permit for a dApp but was actually given to the attacker.

When users sign a permit, they can only see who to authorize, but they don’t know what operations will be paired with it to execute.

Note: The current permit design is not compatible with repetitive operation dApps, such as DCA or other regular payment applications. This is because the permit has a replay protection mechanism, so once a transfer is completed, the same permit cannot be used again, which means that users have to sign a permit in advance for each future repetitive operation.

However, EIP-3074 brings an opportunity for change: when dApp developers know that EOA can perform various complex operations through Invoker, the design of dApp interaction no longer needs to sacrifice security in order to improve the user experience, such as “users pre-approve a large amount of money” and “users sign a permit message to authorize withdrawal.” Instead, users tie dApp operations to approve and perform atomic execution through Invoker: either approve and dApp operations are successfully executed together, or they fail together. There is no possibility of success for approval alone, so users can be confident that this approval is for this operation. And users are using off-chain signature authorization, so the user experience is the same as permit! This means that dApp will no longer need the permit mode! In the future, wallets can directly ban or conduct stricter reviews of permit signature requests, without having to worry about whether it will cause users to not use some dApps (but in turn be used for scam).

Users no longer simply authorize a certain address, but authorize a certain address and what to do, and even see the simulated execution result.

Note: This does not mean that scams can be completely blocked! Users may still be tricked into scam websites, and scam websites can still organize approve or transfer operations for users to sign, but at this time users can at least see what this signature is going to do, and wallets can even simulate display execution results and present them to users, so that users can clearly know who will lose how much money and who will gain how much money. Compared with permits that don’t know what operation or even execution result, users have more information to decide whether to authorize. Although it is not a perfect cure, it will still be a substantial improvement to the current situation.

How the Wallet Handles EOA nonces

The current EIP-3074 design will include the EOA nonce value in the signature content, so as long as EOA sends a transaction to the chain for execution and changes the nonce value, all original EIP-3074 authorizations will be invalidated.

If the user is authorizing someone else to operate the EOA, such as the Session Key or Social Recovery method mentioned above, the nonce of the EOA must be prevented from changing. Otherwise, it is necessary to sign all authorizations again and give them to the trustee, which has a considerable impact on the user experience and the robustness of the mechanism.

If the user is authorized to operate by himself, there is no need to specifically prevent the EOA nonce from being changed, because the EIP-3074 signature is still expected to be executed before a certain deadline like the transaction. It’s just that the wallet needs to manage more EIP-3074 transactions of the EOA: if there are EIP-3074 signatures waiting to be uploaded to the chain, then the transactions of the EOA itself will have to wait.

Note: The Invoker contract itself will (and should) maintain a set of nonce mechanisms, so after the signature is used, it still needs to be signed again, regardless of whether the EOA nonce changes.

Session Key and Social Recovery will most likely have to wait until EIP-3074 changes the rules to remove the EOA nonce from the signature content before they can be adopted on a large scale. Therefore, the wallet only needs to focus on the use case of “user-authorized operations” and treat the EIP-3074 signature as a transaction. There is no need to worry about avoiding EOA sending transactions or changing the EOA nonce.

However, it should be noted that if the user wants to bring his own EIP-3074 signature content to the chain, there will be two disadvantages:

1. The user needs to sign twice: once for the EIP-3074 signature, and once for the on-chain transaction signature.
2. Because the on-chain transaction will add 1 to the EOA nonce before the transaction starts to execute, the EOA nonce in the user’s EIP-3074 signature needs to be pre-added 1 to match the EOA nonce +1 caused by the chain itself.

Because the chain will add 1 to the EOA nonce first, the verification of the EIP-3074 signature will fail due to mismatching EOA nonce.

If users add 1 to the EOA nonce in the EIP-3074 signature before bringing it onto the chain themselves, the verification can proceed smoothly.

Summary and Highlights

• EIP-3074 allows EOA to obtain the same rich execution capabilities as contracts, opening up many new application scenarios.
• This will not only greatly improve the user experience, but will also change the current token authorization method, making it safer while maintaining the same user experience.
• Moreover, EIP-3074 is a simple signature, and users do not necessarily have to bring the signature onto the chain for execution, so there’s no need to worry about gathering ETH to pay transaction fees.
• The uses of EIP-3074 include Batch Call, Session Key, Native ETH Permit, Limit Order, and Social Recovery. Many of these were previously impossible for EOAs to achieve, and some, like Limit Order, required unsafe pre-authorization methods to be used.
• EIP-3074 will also change the current token authorization method. The approve method directly authorizes a specific address to have the power to withdraw tokens indefinitely, and it requires the user’s EOA to send a transaction to execute the approve, so the user experience and security are not good; the permit method only requires the user to sign, and each signature will specify the amount and validity period, which greatly improves the user experience and security compared to approve.
• However, the permit is still frequently used in scams. When signing, users can only know whom to authorize, how much, and the validity period, but they do not know what this authorization is for. “What it is for” will be another signature (or transaction). Normal dApps will let users sign the permit and “what it is for”, but they will still be two different signatures, so when requested to sign the permit, neither the user nor the wallet can know what this permit will be used for.
• With EIP-3074, users (1) do not need to approve a large amount of money to dApp in advance, but only need to approve when there is an operation, which has the same effect as the permit; (2) it is just a simple signature and does not need to worry about gathering ETH to pay the transaction fee, which is the same as the permit; (3) each approval is tied to a specific operation and signed together, so users can clearly know what this approval is for, which will be safer than the permit!
• It is hoped that EIP-3074 can successfully replace the current approve and permit modes and provide users with a more secure authorization method.

Disclaimer：

1. This article is reprinted from [imToken Labs]. All copyrights belong to the original author [Nothing]. 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.