Botanix Labs
Try TestnetBuild dAppsVisit website
  • 🕷️Welcome!
  • 🕷️Get to know the Technology
    • Introduction to Botanix Labs
    • Risk warning
    • Terminology
    • Basic knowledge
      • Proof-of-Stake
      • Ethereum Virtual Machine (EVM)
      • UTXO vs Account Based Model
    • Introductory concepts
      • The Botanix EVM
      • The Spiderchain
      • Orchestrator node
      • Deposit & Withdraw
      • Transaction fees
    • Advanced concepts
      • Bitcoin security inheritance
      • Bridging
      • Consensus
      • Finality
        • Finality in a Proof-of-Work (PoW)
        • Finality in a Proof-of-Stake (PoS)
        • Finality on Botanix EVM
      • Forward security
        • Forward security in cryptography
        • The Spiderchain's Forward Security
        • Inventory management
      • FROST
      • Reth
      • Orchestrators
      • Staking
    • Roadmap to Spiderchain
      • Single Node (Testnet)
      • Botanix Federation
        • Consensus - CometBFT
          • Byzantine Fault Tolerance (BFT)
        • Node types
        • Multisig details - FROST
        • Peg-in / Peg-out
      • Botanix Federation with Staking
      • Slashing
      • Spiderchain DynaFed
      • Permissionless staking
      • Fully Decentralized Layer 2
    • Deeper dive: Whitepaper
  • 🕷️How to use the Botanix EVM
    • Getting started with the Botanix EVM (testnet)
    • Risk warning
    • Step 1 - Set up your wallet
    • Step 2 - Get test funds
    • Step 3 - Send a transaction
    • Step 4 - Use dApps
    • Step 5 - Deploy your first contract / Launch your own token
    • Step 6 - Withdraw
    • FAQ - Testnet V1
  • 🚀Build dApps
    • Introduction
    • Risk warning
    • Tools
      • Useful links
      • Development Frameworks
      • Web3 libraries and tools
      • Oracle Tools
      • Block explorer
        • Routescan
      • Indexers
        • The Graph
        • SubQuery
      • WalletConnect
      • Account Abstraction with BTC Connect
      • Muticall3
    • Build on the Botanix EVM
      • Basic Botanix EVM Information
      • Gas fees
      • Develop a new dApp
      • Migrate existing dApps
      • Quickstart - Build a dApp with Botanix (Solidity, Hardhat)
  • 🕸️Run a node
    • Introduction
    • Run an RPC Node
  • 📔Glossary
Powered by GitBook
On this page
  • The Role of Gas Fees in the EVM
  • The Problem with Hardcoded maxPriorityFee in Ethers.js
  • The Fix: Calculating the maxPriorityFee Dynamically
  1. Build dApps
  2. Build on the Botanix EVM

Gas fees

Understanding Gas Fees on the EVM and How to Optimize Transaction Costs

TL;DR

Some versions of the Ethers.js library hardcode the maxPriorityFee to 1.5 gwei which may be unnecessarily high depending on the current base fee. To avoid overpaying for a transaction, calculate the maxPriorityFee manually.

Gas fees are a critical component of the Ethereum Virtual Machine (EVM) ecosystem, ensuring that the network remains secure and efficient. They incentivize validators to process transactions and execute smart contracts, playing a pivotal role in maintaining decentralized operations.

The Role of Gas Fees in the EVM

Every transaction on the EVM requires computational resources, and gas fees are the mechanism by which users pay for those resources. Gas fees consist of two main components:

  1. Base Fee: Introduced with Ethereum's London Hard Fork (EIP-1559), the base fee is a mandatory, network-determined amount that adjusts dynamically based on network demand. It is burned, reducing the total ETH supply, which helps stabilize gas prices over time.

  2. Priority Fee (Tip): The priority fee is an optional amount that users can include to incentivize miners or validators to prioritize their transactions. This tip is paid directly to the miner or validator and is in addition to the base fee.

The Problem with Hardcoded maxPriorityFee in Ethers.js

The popular Ethers.js library, widely used by developers for building decentralized applications (dApps), hardcodes the maxPriorityFee to 1.5 gwei in some versions. While this value might suffice in high-demand situations, it often leads to users overpaying for transactions, particularly when network or application demand is low.

Example Scenario

  • Base Fee: 0.000000008 gwei

  • Max Priority Fee: 1.5 gwei (hardcoded by Ethers.js)

In this scenario, the priority fee is disproportionately high compared to the base fee. Instead of paying a small additional amount to incentivize miners, the user ends up paying almost the entire transaction cost as a tip. This inefficiency can significantly increase transaction expenses, especially for frequent users or in low-cost networks like Botanix.

The Fix: Calculating the maxPriorityFee Dynamically

To prevent overpayment, developers should avoid relying on the hardcoded maxPriorityFee value provided by Ethers.js. Instead, they can calculate an appropriate priority fee dynamically based on the current base fee and network conditions.

Steps to Calculate the maxPriorityFee Dynamically

  1. Fetch the Current Base Fee Use the network’s RPC endpoint to retrieve the current base fee from the latest block.

  2. Calculate an Appropriate Priority Fee Determine a reasonable multiplier or fixed amount relative to the base fee. For example:

    const priorityFee = Math.max(baseFee * 2, 0.0001); // Example logic
  3. Override the Default Ethers.js Behavior Explicitly set the maxPriorityFee when sending transactions:

    const transaction = {
        to: recipient,
        value: amount,
        maxPriorityFeePerGas: priorityFee,
        maxFeePerGas: baseFee + priorityFee
    };
    await signer.sendTransaction(transaction);

By calculating the maxPriorityFee dynamically, developers can significantly reduce transaction costs for their users while ensuring fair compensation for validators.

PreviousBasic Botanix EVM InformationNextDevelop a new dApp

Last updated 3 months ago

🚀