Here's how Paymasters get rid of them, step by step:
Paymasters are smart contracts that can handle gas fees for users, so users don't need ETH in their accounts.
This lets users pay for gas however they like. Projects can also pay fees directly for users of their app!
Paymasters are part of ERC-4337. All user operations, the ERC-4337 transaction object, can specify a Paymaster, and anyone can create a paymaster.
There are four major steps:
Step 1
The paymaster deposits ETH (or the blockchain's native token) into the Entry Point.
The Entry Point is the contract that handles the validation and execution of ERC-4337 transactions.
Step 2
When the Entry Point receives a user operation with a nonzero paymasterAndData field, it calls verifyUserOp on the corresponding Paymaster contract.
Step 3
The paymaster contract returns approval, and the Entry Point uses the paymaster's deposit to cover the gas fee.
The paymaster doesn't just return approval - it returns validation data and context.
Step 4
If the paymaster returned information in the context object, a postOp function is run after execution.
There are two broad categories of paymasters: those that have their logic on-chain or those that have their logic off-chain.
When the logic is off-chain it is called a Verifying Paymaster.
Some off-chain service decides whether to sponsor the transaction and returns a signature. If the signature is valid, the paymaster will pay.
On-chain paymasters are usually Deposit Paymasters.
It uses an oracle to charge the user ERC-20 tokens for gas and pulls tokens from the account.
The user must make an initial token deposit (which requires gas), and can only be sent to bundler mempools whitelisting it.
These are broad classifications. In theory, you could have a hybrid, where the initial deposit into a deposit paymaster is made with a verifying paymaster.
I'm the cofounder of @stackup_fi - follow me for more information about account abstraction and ERC-4337!
• • •
Missing some Tweet in this thread? You can try to
force a refresh
Bundlers need some assurance that the network state will not change on a layer 2 blockchain between the time a bundler does its checks and the transaction is included.
This would lose bundlers money.
To fix this, Yoav proposes a new RPC request.
The request is eth_sendRawTransactionConditional, which acts just like eth_sendRawTransaction but includes some lightweight checks for the sequencer so the bundler doesn't submit an invalid bundle.
Wow, lots of excitement and questions about ERC-4337!
I'm going to address a few of the common questions and concerns people have about it:
"Account abstraction has existed before! What's new about this?"
This is true! Smart accounts have existed before, notably Safe and Argent.
Three things make it stand out.
Standout 1:
Unlike other implementations of account abstraction including Argent, Safe, Biconomy, Gelato network, and so on, it provides a decentralized relay system so it's censorship resistant.