1. Summary
This proposal introduces a solution for facilitating gasless transactions, while also ensuring compatibility with existing mainstream wallets.
2. Abstract
Under the BEP322: Proposer Builder Separation architecture, the proposer doesn’t check the gas price of each transaction within a block, allowing transactions with zero gas price. Transactions are grouped in a bundle submitted to the builder, who prioritizes based on the whole gas price of a bundle. Transaction gas prices can be set to zero for some and higher for others in the same bundle to enable features like sponsor gas fee or gasless transactions.
3. Status
Draft.
4. Motivation
There is a growing interest in making it possible for BSC contracts to accept calls from externally owned accounts that do not have BNB to pay for gas. There are several EIPs such as EIP-4337, EIP-3074, and EIP-2771 related to gasless transactions, which either need extra integration of Wallet, or modification of dapp contracts. Because of the insufficient ecosystem facilities, it will take a significant amount of time for these EIPs to be fully implemented and operational. This BEP tries to propose a new gasless tx solution that can seamlessly integrate with current web3 infrastructure.
5. Specification
5.1 Definitions
Bundle: an ordered array of transactions that execute atomically.
Builder: new stakeholders in the MEV supply chain responsible for packaging transaction bundles, along with individual transactions from the public mempool and private transaction order flow, into blocks.
Proposer: validators who chooses the most profitable block from multiple builders.
Paymaster: the entity that sponsors the transactions from the user.
5.2 Workflow
To set up the wallet, users simply need to update the RPC endpoint of their wallet to the one provided by Paymaster. The dapp can call the wallet to add a custom endpoint network, facilitating users in completing this step.
Any existing Ethereum wallet can seamlessly connect to the paymaster. As the paymaster can return zero value when the dapp requests the suggested gas price, the user will send zero gas price transaction to the paymaster. The paymaster adds one transaction with a higher gas price to the user’s transaction to create a bundle, and sends the bundle to a builder. Both the user’s transaction and the payment from the paymaster for the gas are eventually included on the chain.
As the paymaster is an off-chain service, the implementation can be extremely flexible. The modules in paymater are simply categorized into four parts.
- ETH RPC Proxy. It is the gateway that serves RPC requests. Besides the eth_sendRawTransaction request, almost all other requests will be forwarded to the real RPC node or services.
- Authentication module. It will verify whether the paymaster should sponsor the tx or not. The validation rules here can be flexible. For instance, they can check if the sender holds a certain amount of a particular token, or if the gas fees sponsored to the tx sender in the past day exceed a specific limit, or by simulating this transaction, it verifies whether a specific amount of a certain token has been paid to the paymaster’s account.
- Risk control module. It is used to apply some strategies to avoid paying too much gas fee.
- Tx signer. It is used to sign a new transaction with a higher gas price, and then bundle it together with the user’s transaction, which is then sent to the builder.
5.3 Payment
A paymaster needs incentive to provide stable services over the long term. A few examples are listed.
5.3.1 Pay with Paymaster Tokens
The paymaster can issue a BEP20 token, anyone can buy it to pay for the service. The user will approve the paymaster to transfer this token in advance. The paymaster will deduct a specific amount of tokens from the user’s account in the transactions it appends to the bundle. The drawback of this solution is the necessity for users to trust the paymaster.
5.3.2 Pay with Stable Coin
The user gets a stable coin in his account and approves a number of tokens that paymaster can spend. The paymaster can charge the stable coin in its assembled tx in the bundle.
5.3.3 Pay in User’s Transaction
For users who do not want to trust paymaster and want to include the BEP20 token transaction to the paymaster account in their own transaction, they need to deploy a new contract to handle the interaction with native dApps. For example, when a user does a swap on the uniswap dapp, he can not pay to the paymaster because the uniswap contract does not support this. He has to deploy a new contract and interact with the new contract directly, and the new contract will call uniswap and pay to the paymaster in one tx.
5.3.4 Free Quote
The paymaster can provide a free quota gas fee for each account before the user buys its service.
5.3.5 Monthly Subscription
For users who send a large number of transactions, they can also choose a monthly/yearly subscription.
5.4 Compare
| Gas Cost | Account Type | Compatibility with Dapp | Compatibility with Wallets | Trust model | |
|---|---|---|---|---|---|
| EIP 4337 | High | Contract Account | Need integration | Need integration | trustless |
| EIP 3074 | Low | EOA | Need integration | Need integration | trustless |
| MEV Paymaster | Moderate | EOA | Fully compatible | Almost fully compatible | trust to paymaster in some case |
5.5 Security
In a transaction bundle, if one transaction fails, the whole bundle won’t be added to the blockchain, ensuring atomicity. Bundles are kept private between the builder and validator through the protocol, preventing exposure to others on the network. This privacy and atomicity protect the paymaster from funding failed or leaked transactions, avoiding financial losses.
Users can seamlessly experience native dapps when they have a trusted relationship with the paymaster. The scenario that best suits this approach is when a specific dapp can flexibly construct a paymaster according to its specific needs. The dapp can then sponsor its own users or pay gas fees using tokens within the dapp.
- License
The content is licensed under CC0.