TechFlow: A Deep Dive into the Impact of EIP-3074 on Wallets and DApps
TechFlow Selected TechFlow Selected
TechFlow: A Deep Dive into the Impact of EIP-3074 on Wallets and DApps
EIP-3074 enables EOAs to have execution capabilities as rich as smart contracts, unlocking numerous new application scenarios.
Navigating Web3 tides with focused insightsAuthor: Nic @ imToken Labs
EIP-3074
Better and Safer User Experience
EIP-3074 allows EOAs to delegate control to designated contracts, thereby gaining execution capabilities as rich as those of smart contracts.
Before EIP-3074, each transaction sent by an EOA could only perform one operation, such as approving an ERC20 token or swapping on Uniswap. With EIP-3074, an EOA can now execute multiple operations at once—or even enable previously unimaginable use cases.
In short, EIP-3074 significantly improves the user experience. Current authorization methods will be reshaped, enhancing security without compromising usability.
Moreover, with EIP-3074, EOAs no longer need to send transactions themselves, eliminating the need to first acquire ETH to pay gas fees.
Invoker Contract
A contract capable of obtaining control over an EOA is called an Invoker contract. However, not just any contract can gain this control: the EOA must sign with its private key, explicitly specifying which Invoker contract is authorized and what actions it may perform.
The EOA's signature clearly specifies the Invoker contract address and the permitted operations (commit).
The actual execution flow would look like this:
-
Alice signs with her EOA private key and sends the signed message and signature to a Relayer.
-
The Relayer submits the data on-chain to trigger execution in the Invoker contract.
-
The Invoker verifies the signature. Upon success, it executes operations on behalf of the EOA—such as approving USDC, swapping on Uniswap, and paying the Relayer in USDC for gas.
Note 1: A Relayer is optional; Alice can submit the signature herself.
After verifying the signature, the Invoker performs all operations under Alice’s EOA identity—as if granted limited control over the EOA.
However, note that execution does not increase the EOA’s nonce. Therefore, the same signature could potentially be reused (as long as the EOA’s nonce remains unchanged), so the Invoker must implement its own nonce mechanism to prevent replay attacks.
If the Invoker lacks replay protection, the same authorization can be executed repeatedly.
Learn more about how EIP-3074 works: https://medium.com/taipei-ethereum-meetup/eip3074-%E7%B0%A1%E4%BB%8B-2a880b918234
Use Cases
Batchcall
Allows users to combine multiple intended transactions into a single execution, saving repeated signing steps and reducing gas costs.
Note: This requires DApp support for batchcall functionality, such as the community-driven EIP-5792. Otherwise, if the DApp treats the user as a standard EOA, it will still prompt for a separate signature per operation.
For details on EIP-5792, copy the link to your browser: https://eips.ethereum.org/EIPS/eip-5792
Session Key
Users can allow third parties to act on their behalf under specific conditions. In the diagram below, the "delegate key" refers to an authorized third party; "access policy" defines execution constraints—such as limiting operations to Uniswap, capping daily transfers at 1 ETH, or setting an expiration date.
These rules are enforced within the Invoker contract. As long as they pass validation, the third party can execute actions using the user’s EOA identity.
A Telegram bot can be granted specific permissions to act on behalf of the user’s EOA.
Native ETH Permit
When conditions are met (i.e., the permit signature is valid), ETH transfers can be executed on behalf of the authorizing EOA, achieving native ETH permit functionality.
Limit Order
Users set limit order conditions. When fulfilled, the system executes on their EOA’s behalf—including approving assets to a DEX and performing swaps. Compared to DEX-native limit orders, users no longer need to pre-approve transactions.
Alice approves assets during execution—no prior approval needed.
By generalizing these conditions, this becomes similar to an Intent contract: whenever a user-defined condition is satisfied, anyone can execute the intent on their behalf.
Once the intent condition is met, anyone can initiate execution on the user’s EOA behalf.
Social Recovery
When a user loses their EOA private key, they can leverage a pre-signed EIP-3074 authorization along with signatures from trusted parties (e.g., spouse or trust agent) to transfer all assets out of the compromised EOA. What is actually recovered is the (transferable) asset—not account control. Once the EOA key is lost, the EOA itself becomes unusable.
When a user loses their EOA key, previously authorized individuals can sign to authorize asset transfers from the EOA.
Impact of EIP-3074
Improving Asset Authorization—Could It Replace Approve/Permit?
Currently, DApps are designed assuming users operate via EOAs: users must “pre-approve” a large amount of assets to the DApp contract so they don’t need to stay online waiting for execution or repeatedly approve. This greatly enhances user experience.
For conditional applications like limit orders or DCA, users may not be online when conditions are met, so they must pre-approve large amounts for repeated execution by the DApp.
Users must pre-approve sufficient assets to the DApp for seamless operation.
But this requires trusting the DApp and avoiding fake ones, and being able to revoke approvals promptly.
Later, permit-style patterns emerged—like EIP-2612 or non-native Permit2—to improve the usability and security of the approve model: instead of approving large amounts to various DApp contracts (once per asset), users only need to “sign once” to authorize a DApp to withdraw a specified amount within a time window. This greatly reduces the attack surface while improving user experience.
Learn more about EIP-2612: https://eips.ethereum.org/EIPS/eip-2612
About Permit2: https://medium.com/taipei-ethereum-meetup/uniswap-permit2-introduction-858ae3dddf18
Users only need to sign off-chain, specifying amount and validity period—offering better usability and security than approve.
Yet in practice, the permit pattern continues to be exploited in scams: victims mistakenly sign what they believe is a permit for a legitimate DApp but actually grants access to an attacker.
When signing a permit, users can only see who is being authorized—not what operations it will be used for.
Note: Current permit designs also don’t support recurring operations like DCA or subscription payments, because permits include anti-replay mechanisms. After one withdrawal, the same permit cannot be reused—meaning users must pre-sign future permits for every recurring action.
Learn more about permit-related scams: copy links to browser:
https://x.com/realScamSniffer/status/1783027808723435727
https://x.com/realScamSniffer/status/1784932506174967970
https://x.com/realScamSniffer/status/1786738218962223226
However, EIP-3074 presents a turning point: once DApp developers realize EOAs can perform complex operations via Invokers, interaction design no longer needs to sacrifice security for usability—such as requiring users to pre-approve large asset amounts or sign generic withdrawal permits.
Instead, users can bind DApp actions directly with approvals, executing atomically through an Invoker: either both the approval and DApp action succeed, or both fail. There’s no chance of approval succeeding alone. Thus, users can be confident that each approval is strictly tied to a specific action.
And since users authorize via off-chain signatures, the experience is as smooth as with permit. This means DApps may no longer need the permit model! Wallets could then block or strictly audit permit signing requests, without worrying about breaking DApp functionality (which currently risks enabling scams).
Users no longer simply authorize an address—they authorize an address and specific actions, and may even preview simulated execution results.
Note: This doesn’t eliminate scams entirely! Users could still be tricked into visiting malicious sites that request signatures for approve or transfer operations. But now, users can at least see what the signature enables. Wallets might even simulate and display execution outcomes—clearly showing who gains or loses funds. Compared to blind permit approvals where users don’t know the consequences, this provides far more information for informed decisions. While not perfect, it represents a significant improvement.
How Wallets Should Handle EOA Nonce
Current EIP-3074 design includes the EOA nonce in the signed message. So, once the EOA sends any transaction changing its nonce, all existing EIP-3074 authorizations become invalid.
If a user has delegated EOA control—such as via Session Key or Social Recovery—then the EOA nonce must remain unchanged. Otherwise, all authorizations must be re-signed and re-distributed, negatively impacting both user experience and system robustness.
If the user self-authorizes, there’s less concern about nonce changes, as EIP-3074 signatures are expected to be executed within a timeframe—just like regular transactions. However, wallets must manage pending EIP-3074 signatures: if one is waiting to be submitted, the EOA’s own transactions should wait.
Note: The Invoker contract itself should maintain its own nonce mechanism, so signatures must be renewed after use—regardless of EOA nonce changes.
Widespread adoption of Session Key and Social Recovery likely depends on modifying EIP-3074 to remove the EOA nonce from the signature. Until then, wallets should focus on self-authorization scenarios, treating EIP-3074 signatures like regular transactions—without needing to avoid EOA-initiated transactions or nonce changes.
However, note that if users submit their own EIP-3074 signatures on-chain, two drawbacks arise:
-
Users must sign twice: once for EIP-3074, once for the on-chain transaction.
-
Since the on-chain transaction increments the EOA nonce before execution begins, the EIP-3074 signature must anticipate this—its included EOA nonce must already be +1 ahead to match the incremented value.
Because submitting on-chain increments the EOA nonce upfront, EIP-3074 signature verification will fail due to nonce mismatch.
If the user pre-increments the EOA nonce in the EIP-3074 signature, verification proceeds successfully.
Summary & Key Takeaways
-
EIP-3074 grants EOAs execution capabilities comparable to smart contracts, unlocking many new use cases.
-
This dramatically improves user experience and will transform current authorization models, making them more secure without sacrificing usability.
-
EIP-3074 relies solely on signatures—users don’t need to submit transactions themselves, eliminating the need to gather ETH for gas fees.
-
EIP-3074 use cases include Batch Call, Session Key, Native ETH Permit, Limit Order, and Social Recovery—many previously impossible for EOAs, and some (like Limit Order) previously required risky pre-authorizations.
-
EIP-3074 will reshape current authorization practices. Direct approve grants indefinite withdrawal rights to a designated address and requires an on-chain transaction, resulting in poor usability and security. Permit only requires a signature, specifying amount and validity period—offering major improvements in both areas.
-
Yet permit is still frequently abused in scams. At signing, users only know the recipient, amount, and duration—but not what the authorization will be used for. That context comes from another signature (or transaction). Legitimate DApps typically ask users to sign both the permit and the action, but these remain separate signatures—so neither user nor wallet knows how the permit will be used.
-
With EIP-3074, users (1) no longer need to pre-approve large asset amounts to DApps—approvals happen just-in-time, with the same convenience as permit; (2) only sign off-chain without worrying about gas ETH, just like permit; (3) each approval is bound to a specific action and signed together, so users clearly know what the approval is for—making it safer than permit!
-
We hope EIP-3074 successfully replaces current approve and permit models, offering users a more secure authorization method.
Join TechFlow official community to stay tuned
Telegram:https://t.me/TechFlowDaily
X (Twitter):https://x.com/TechFlowPost
X (Twitter) EN:https://x.com/BlockFlow_News
@imTokenOfficial
