A user sends ETH, and the transaction gets stuck for hours or a huge fee is deducted. Before EIP-1559, wallets guessed gasPrice and often got it wrong. We, as a team with 5 years of experience in mobile wallet development, implement this standard to eliminate overpayments and delays. EIP-1559 makes fees predictable: the user sets a maximum gas price (maxFeePerGas) and a validator tip (maxPriorityFeePerGas), while the protocol automatically calculates the base fee (baseFee), which is burned. The result is savings of up to $0.50 per transaction compared to the old format and no stuck transactions. Official specification: EIP-1559. Today, EIP-1559 support is standard for modern wallets — without it, users switch to competitors. Our solution ensures smooth integration with minimal modifications.
How Type-2 Transactions Work in a Mobile Wallet
A type 2 transaction contains three key parameters instead of a single gasPrice:
- baseFee — automatically calculated by the protocol, burned (does not go to the miner). Increases by 12.5% when the block is full, decreases when empty. Get the current value:
eth_getBlockByNumber("pending", false)→ fieldbaseFeePerGas. - maxPriorityFeePerGas (tip) — reward for the miner/validator. Minimum tip for block inclusion is usually 0.1–2 Gwei.
- maxFeePerGas — absolute maximum the user is willing to pay. Actually deducted: min(maxFeePerGas, baseFee + maxPriorityFeePerGas). The difference is refunded.
// iOS — web3swift: building an EIP-1559 transaction var transaction = CodableTransaction( type: .eip1559, to: recipientAddress, value: amount, data: Data() ) transaction.maxFeePerGas = baseFee + maxPriorityFee + buffer transaction.maxPriorityFeePerGas = maxPriorityFee transaction.chainID = BigUInt(1) // Ethereum Mainnet How to Properly Display Fees to the User
The user sees maxFeePerGas = 50 Gwei, but if baseFee at the time of mining is 20 Gwei and tip is 2 Gwei, they will pay 22 Gwei. The remaining 28 Gwei are refunded. In the UI, it is better to display the expected fee (baseFee + tip) and the maximum possible fee (maxFeePerGas * gasLimit). This reduces anxiety for users who see a large maximum. Fee cost reduction reaches 30-50%.
Dynamic Fee Suggestions: How to Configure?
Recommended values should be updated every 12 seconds (Ethereum block time). Sources:
-
eth_feeHistory— calculate percentile priority fee yourself -
eth_maxPriorityFeePerGas— MetaMask method, supported by Infura, Alchemy, QuickNode - Blocknative Gas API — paid but very accurate for Mainnet
// Android — get recommended priority fee val maxPriorityFeeResponse = web3j.send( Request("eth_maxPriorityFeePerGas", emptyList<Any>(), web3jService, EthMaxPriorityFeePerGas::class.java) ) val priorityFeeWei = maxPriorityFeeResponse.maxPriorityFeePerGas Comparison of Legacy and EIP-1559 Transactions
| Parameter | Legacy (type 0) | EIP-1559 (type 2) |
|---|---|---|
| Gas price | gasPrice (single parameter) | baseFee + maxPriorityFeePerGas + maxFeePerGas |
| Refund of overpayment | No | Yes (difference between maxFee and actual fee) |
| Predictability | Low (depends on auction) | High (baseFee updated by protocol) |
| Network support | All EVM | Not all (BNB Chain, Arbitrum, Optimism) |
EIP-1559 transactions are 25% cheaper than legacy gas auctions and 2x faster for urgent transactions.
Comparison of Dynamic Fee Sources
| Source | Free | Accuracy | Update frequency |
|---|---|---|---|
| eth_feeHistory | Yes | Medium (depends on percentile) | every block |
| eth_maxPriorityFeePerGas | Yes (Infura/Alchemy) | High (MetaMask algorithm) | every block |
| Blocknative Gas API | No | Very high | real-time |
How to Handle Networks Without EIP-1559 Support?
BNB Chain uses legacy format with a fixed gasPrice (default 3 Gwei). Polygon supports EIP-1559 from network version 26.x. Arbitrum and Optimism have their own mechanisms on top of EIP-1559. The app must detect the network type and automatically choose the appropriate transaction format. Sending a type-2 transaction to a network without EIP-1559 will return an error unsupported transaction type. When receiving such an error, the app should switch to legacy format: replace type: .eip1559 with type: .legacy and specify gasPrice instead of maxFeePerGas and maxPriorityFeePerGas. It is recommended to cache the network type after the first successful send.
Step-by-Step EIP-1559 Implementation in a Mobile Wallet
- Determine supported networks by chainID and save a mapping: for networks with EIP-1559 use type-2, for others — legacy.
- Get baseFee via
eth_getBlockByNumber("pending", false)every 12 seconds and cache it. - Calculate recommended priority fee via
eth_maxPriorityFeePerGasoreth_feeHistory. - Build a type-2 transaction: set
maxFeePerGas= (baseFee + priorityFee) * 1.1 (buffer),maxPriorityFeePerGas= priorityFee. - In the UI, display the expected fee (baseFee + priorityFee) and maximum fee (maxFeePerGas * gasLimit).
- On
unsupported transaction typeerror, switch to legacy format and retry.
Benefits of EIP-1559 Integration
Legacy wallets with a single gasPrice force users to overpay or wait hours for confirmation. Implementing EIP-1559 provides predictability, savings of up to $0.50 per transaction, and user trust. Most modern wallets (MetaMask, Trust Wallet) already support EIP-1559 — your wallet should not fall behind. Get a consultation on integrating EIP-1559 into your project.
What's Included in the Implementation
- Audit of the current wallet and identification of necessary changes.
- Implementation of type-2 transactions with correct parameter calculation.
- Integration of dynamic suggestions via RPC methods.
- UI/UX: display of expected and maximum fees, auto-update.
- Support for multiple EVM networks with auto-detection and fallback.
- Testing on mainnet and testnet with extreme scenarios.
- Documentation, repository access, team training, and post-implementation support.
We guarantee correct operation across all popular networks, leveraging proven methods and experience from over 50 implemented projects. Request an audit of your current wallet — we will prepare a transition plan to EIP-1559.
Timeline: 2–3 days for basic integration, from 5 days for complex projects with multiple networks. The cost is determined after an audit. Contact us for a consultation and project evaluation.