🚀 From Permit to EIP-7702: Modern Patterns for One-Step ERC-20 Approve & Transfers

One of the biggest friction points in ERC‑20 token usage is the two-step approve + transfer flow. EIP-7702 is the true game changer!

Most ERC‑20 interactions require users to first call approve() and then transferFrom(). This is clunky, doubles gas fees, and creates a bad UX.

Fortunately, modern patterns let you collapse this into a single user interaction. Below, I’ll walk through three practical approaches — all implemented and tested in my GitHub repo so your dApp can transfer tokens in one smooth flow.

In my example, we have a Staking Vault that would perform transferFrom in behalf of the user to lock some ERC-20 tokens in the vault, which would need to be approved ahead.

1. Permit (EIP‑2612)

A standardised way for users to sign an off-chain approval that a contract executes on-chain. Eliminates the need for a separate approve() transaction, instead you would use permit.

How it works:

1. The user signs a typed data permit off-chain and call a gas-less permit.
2. The contract executes transferFrom() in a single transaction.

Example:

IERC20Permit(token).permit(
    msg.sender,
    address(this),
    amount,
    deadline,
    v, r, s
);
IERC20(token).transferFrom(msg.sender, address(this), amount);

const signature = await user.signTypedData({ /* domain, Permit type */ });
await token.permit(owner, vault.address, amount, deadline, v, r, s);
await vault.deposit(token.address, amount);

⚡ Pros:

• Single transaction for the user
• No on-chain approval needed

⚠ Cons:

• Only works with tokens that implement EIP‑2612

2. ERC‑1363: Transfer with Callback

ERC‑1363 extends ERC‑20 with extra callback functions, letting the receiving contract react immediately when tokens arrive:

• transferAndCall
• approveAndCall

Instead of calling approve() and transferFrom(), the receiving contract executes logic in a callback (onApprovalReceived or onTransferReceived).

Example:

token.approveAndCall(stakingVault, amount, data);
token.transferAndCall(stakingVault, amount, data);

The receiving contract implementing IERC1363Receiver and IERC1363Spender gets an immediate callback:

onApprovalReceived(...)
onTransferReceived(...)

⚡ Pros:

• Single transaction for the user
• Automatically triggers contract logic

⚠ Cons:

• Requires a modified token supporting ERC‑1363
• Not compatible with legacy tokens

🌟 3. The Game changer — EIP‑7702 (EOA Delegation)

Allows an externally owned account (EOA) to temporarily delegate execution to a batch contract, running multiple calls atomically (e.g., approve + transferFrom).

How it works:

1. The EOA signs a delegation authorization (EIP‑7702).
2. A single transaction executes approve + deposit in one atomic operation with a deployed batch contract.
3. Works with any ERC‑20 token, including legacy ones.

Example:

const tx = {
  to: eoaAddress,
  data: encodeFunctionData(BatchExecutor, "executeBatch", [
    [token, vault],
    [0, 0],
    [approveCalldata, depositCalldata]
  ]),
  authorizationList: [signedAuthorization],
};

⚡ Pros:

• Works with all ERC‑20 tokens
• No token upgrade needed
• Keeps the same EOA address
• Atomic single transaction

⚠ Cons:

• Requires network support for EIP‑7702

📊 Comparison Table

📝 Conclusion

You no longer have to force users through a clunky two-step ERC‑20 approval flow.

Whether your token supports EIP‑2612, you can use ERC‑1363 callbacks, or you rely on a batch executor with EIP‑7702, each pattern lets you collapse approve + transfer into a single, smooth experience.

Let’s connect

If you’re exploring options for your smart contracts or want to create a new dApp, I’d love to chat.

📌 Check out my Github repo for working contracts and tests: https://github.com/cladjules/evm-experiment-approve-transfer

📌 Want advice or personalised guidance? Let’s connect: https://linktr.ee/julien.a