When a free gas Hyperledger Besu network fits your consortium
A free gas network is a Besu network where the gas price is zero. Transactions still consume gas, so the block gas limit and per-transaction limits still apply, but no participant pays a fee to submit them. This fits a consortium where the validators are the participants: the organizations that run validator nodes are the same parties that use the ledger, so there is no external fee market and no party that needs a gas incentive. Many private networks choose this model because the cost of running the network is already shared through validator operations, and a per-transaction fee would add a billing layer between members with no operational purpose.
The decision point is whether every participant accepts that transactions carry no economic cost on the ledger. If your settlement or tokenization design depends on fees for spam control, fee revenue for an operator, or pricing signals between members, a free gas model removes those controls, and you will need admission rules and permissioning to replace them. Confirm this with your governance group before any node is built, because the choice shapes genesis settings, node configuration and who can submit transactions.
The settings only work if they are applied consistently across all nodes. A single validator or RPC node that keeps a higher minimum gas price will silently drop zero gas price transactions, so one misconfigured node can look like a network fault. Plan a configuration review that covers every validator and every node that accepts transactions, and check each one against the Besu documentation on free gas networks before go-live and after each Besu upgrade.
Which free gas settings to set and when each one fits
This table compares the Besu settings that shape a free gas network, showing what each one controls, when to move it off its default and what to confirm in the Besu docs. Read it as a checklist: the first four rows apply to most zero gas price networks, while the block gas limit and contract size rows depend on your contract workload.
| Setting | What it controls | When to change it from default | What to confirm in the docs |
|---|---|---|---|
| --min-gas-price=0 | The lowest gas price a node will accept into its transaction pool | Always on free gas networks, set on every node; a single node with a higher minimum silently drops zero gas price transactions | Confirm the flag is set on validators, RPC nodes and any bootnodes, and in the same place your deployment tooling writes node config |
| --tx-pool-enable-balance-check=false | Whether the prioritized transaction pool layer checks sender balance before accepting a transaction | Set to false on free gas networks so zero-balance senders are not blocked from the prioritized layer | Confirm the flag name and its behavior for your Besu version, and test with an account holding no native balance |
| zeroBaseFee on all nodes | Sets the base fee to zero in the genesis configuration on networks running the London fork or later | Required on London or later networks that should have zero base fee; must match across every node | Confirm the genesis key name and placement for your chosen consensus, and whether it applies from the London block or from genesis |
| --tx-pool-price-bump | The minimum percentage increase needed to replace a pending transaction with the same nonce | Cannot be set while zeroBaseFee is enabled, so leave it unset on zero base fee networks | Confirm how replacement transactions behave on your network, since replacement rules change when the price bump is unavailable |
| pertxgaslimit | The per-transaction gas cap on QBFT and IBFT 2.0 networks, which otherwise follows EIP-7825 at 16777216 gas | Set to 0 only when contracts need more gas than the cap allows; 0 disables the cap entirely | Confirm the option is supported on your consensus type, and decide whether an uncapped transaction can exhaust validator resources |
| Block gas limit | Total gas that all transactions in one block can consume | Raise when your workload needs more throughput per block, and size it with validator hardware in mind | Confirm the genesis value and any on-chain or config changes needed for the limit to take effect across validators |
| Contract size limit | The maximum deployed bytecode size a contract can have | Change only when a contract you need to deploy exceeds the default limit, and document the reason | Confirm the genesis or config key that controls it and how it interacts with the per-transaction gas cap |
How to configure every node for a zero gas price network
This sequence takes a private Besu network from an agreed gas policy to verified zero-price transactions, with a check at each stage so that no node silently rejects traffic the network depends on.
Agree the gas policy in governance documents
Before any file is edited, the consortium or the owning team records in its governance documents that the network uses a zero gas price, who may change that decision, and which contracts are expected to be deployed. Operators should confirm that every participant running a node accepts the same policy, because a single node with different settings can change how transactions propagate. The step is complete when the signed policy names the gas price, the block gas limit intent, the largest contract size expected, and the owner of each setting. Ask your governance lead to confirm this in writing.
Set genesis gas and zeroBaseFee values
The engineer who owns the genesis file sets the block gas limit and the contract size settings to match the agreed policy, then enables zeroBaseFee if the network starts at or after the London fork. Because the London rule applies from the chain's start, the genesis must match what every node will load. Check the result by reading the genesis file back in version control and confirming the values, and by starting a single test node that reports the expected chain configuration in its logs.
Apply min-gas-price=0 on every node
Each node operator sets the minimum gas price option to zero in the node configuration file, not only on validators. A node that keeps a higher minimum will silently drop zero gas price transactions, so a partial rollout can look like a network fault. The engineer records the configuration hash or version for each node in the change log. The check is a query of each node's effective configuration, confirming that the minimum gas price reads zero before the node is admitted to the network.
Disable the balance check in the transaction pool
On every node, set the transaction pool balance check to false so that accounts with no native balance are not blocked from the prioritized pool layer. This setting belongs in the same configuration change as the minimum gas price, and the two should be reviewed together. Verify by confirming the option is present on each node and that a node restart loads it. Ask each operator to attest to the value, since a missed node will behave differently under load.
Verify the per-transaction gas cap against your largest contract
Under EIP-7825, each transaction is capped at 16777216 gas even when the block gas limit is higher. Using the contracts planned for deployment, the engineer estimates the deployment gas for the largest one and compares it with that cap. If a deployment would exceed the cap, the QBFT or IBFT 2.0 network can set the pertxgaslimit option, where 0 disables the cap, but this should be a documented governance decision. The check is a recorded estimate for each contract and a sign-off that the cap setting matches the decision.
Confirm the pool and consensus behavior together
Start the full set of validators and observer nodes, then confirm that all nodes report the same chain configuration and that blocks are being produced with the expected validator set. Check that no node has rejected a zero gas price transaction in its logs and that peers remain connected. This step tests the configuration as a whole rather than one node at a time, because the failure modes described above only appear when transactions move across the network. The output is a short log extract from each node showing the same genesis hash and a block height that advances.
Send test transactions from zero-balance accounts
Create at least one new account that holds no native balance, then submit a simple transfer and a contract deployment from it through a node that has the configuration applied. Confirm the transaction is accepted, included in a block, and returns a receipt with the expected status on every node. Repeat the test from an account that has never been funded to confirm the balance check setting is effective. Record the transaction hashes and block numbers in the change record. The sequence is complete when both tests succeed and the results match across the network.
Security and operational risks of a zero gas network
A zero gas price removes the fee that normally makes spam expensive, and it changes how a node behaves when its settings differ from its peers. The cards below cover the controls that must replace fee-based spam resistance, the configuration consistency that keeps transactions flowing, and the key and RPC exposure that remains in any permissioned network.
Access control replaces gas fees
On a free gas network, anyone who can submit a transaction can also submit it at no cost, so fees no longer deter flooding. Node permissioning and account permissioning become the main barriers against unwanted senders. Before go-live, confirm which nodes can connect, which accounts can transact, and who can suspend an account. The permissioning page sets out how these local rules are configured.
Minimum gas price drift
Every node must run with --min-gas-price=0. A node with a higher minimum does not reject zero gas price transactions with an error that operators will notice quickly. It drops them silently, so a transaction can appear to be accepted while it never reaches a block. Include this setting in your configuration review for every validator and every RPC node, not only the ones you built first.
Balance check in the transaction pool
With a zero price, a sender holding no balance can still be blocked from the prioritized transaction pool layer unless the balance check is disabled. Set --tx-pool-enable-balance-check=false on every node. Test the behavior with an account that holds no balance, because the failure is easy to miss when the test accounts are funded.
RPC and node key exposure
The local node private key file is not encrypted, so anyone who reads it can impersonate the node. Besu also does not terminate HTTPS natively, so JSON-RPC traffic needs protection in front of the node or through an encrypted transport you configure. Confirm who can reach each RPC port and where the node key file is stored. The node keys and authentication pages describe the options, including hardware-backed storage through a security module plugin.
Authentication for JSON-RPC access
Besu supports a username and password credentials file or JWTs validated against a public key. Choose one method for each deployment and document which applications use it. A free gas network accepts transactions from any authorized sender, so an exposed RPC endpoint with weak authentication lets an outsider submit zero cost transactions into your chain. Review the authentication setup as part of go-live.
Upgrades that reset settings
Each calendar release can change defaults, and some removed features affect how a node starts. Compare the release notes against your configuration before each upgrade, and apply the same zero gas settings to every node in the same maintenance window. The Bonsai database upgrades on first start and older versions cannot open it, so take a backup before the upgrade. Confirm that the rollback plan works before you begin.
Questions teams ask before configuring a free gas network
What drives the effort to configure and test a free gas network?
The effort is driven less by the flag changes themselves than by how many nodes must agree on them and how much testing proves the network behaves as intended. Every node needs a minimum gas price of zero, the transaction pool balance check has to be disabled, and on networks past London the zero base fee setting must match everywhere. Testing then has to show that zero gas price transactions are accepted by every node, that contract deployments fit within the configured limits, and that the per-transaction gas cap behaves as expected on your chosen consensus. Scope grows with the number of nodes, the number of organizations operating them and the amount of automation already in place for configuration.
What does the work need from our team?
You need a named owner for the genesis file and the configuration of each node, access to every node operator's configuration repository or host, and a test environment that mirrors production topology closely enough to catch a node that silently drops zero gas price transactions. Your team also needs to agree on who approves changes to gas settings, because those settings affect every participant. Ask the partner to list the artifacts they will review and the decisions they expect you to make before work starts.
Can our own engineers configure a free gas network without a partner?
Yes, if your engineers are comfortable with Besu configuration files, genesis settings and rolling restarts of validator and non-validator nodes. The official free gas guide documents the required settings, so a capable team can apply them. The risk is consistency: a single node left with a default minimum gas price can reject transactions that other nodes accept, and that failure may not be obvious until a participant reports it. Many teams keep the work in-house for the initial change and bring in outside help for the testing and drift controls that follow.
How long does the change take across our node count and environments?
No duration is given here. Elapsed time depends on the number of nodes, how many organizations must approve and roll out the change, whether each environment (development, test and production) is changed in sequence, and how much testing your governance requires. Ask any provider for a written schedule that lists each environment, each node group, the test evidence they will produce and the approval points. Ask them to state which steps assume your change windows and which assume a partner-run rollout.
What is the recurring work after go-live?
Once the network is live, the recurring work is keeping every node aligned and checking that the settings have not drifted. Configuration drift is the main concern: a node rebuilt from an old template, or a new node added without the zero gas settings, can start rejecting transactions. Besu also ships releases roughly monthly, and upgrades can change behavior. The 26.10.0 release notes state that the Bonsai database auto-upgrades on first start and older versions cannot open it, so a backup taken before each upgrade is necessary. Plan recurring reviews of the configuration against the genesis file, upgrade testing and a rollback plan.
Which parts of the cost are one-time and which recur?
One-time costs cover the design of the gas settings, the change itself, the test plan and the first round of evidence for your governance team. Recurring costs cover monitoring for drift, reviewing each Besu release against your settings, rehearsing upgrades and restores, and any retained support. Costs rise with the number of nodes, the number of organizations and the number of environments. Ask for a quote that separates these items and states who performs each one, so you can compare an in-house plan with a partner's written scope.
Do free gas settings change how we manage security controls?
Free gas removes the cost of transactions, so the network's protection against spam and abuse must come from other controls. Access to the network should be governed by node and account permissioning, and the balance check is disabled, which means zero-balance senders are not blocked from the prioritized pool layer. Ask your partner how they will verify that only approved participants can submit transactions and how that verification will be recorded for your security and compliance reviews.
What a DeployOpen free gas configuration engagement covers
A DeployOpen free gas engagement covers the configuration work that makes a zero gas price network behave the same way on every node. It starts with a review of the genesis file and each node's configuration, checking the block gas limit, contract size settings, the per-transaction gas cap, the minimum gas price, the balance check in the transaction pool and the zero base fee settings for the fork level your network runs. The review is done against your own environment, including your validator set, the nodes that accept client traffic and any node that sits behind a load balancer, because a single node with a different setting can drop transactions without an obvious error.
From that review, DeployOpen writes a settings baseline that lists each parameter, its agreed value, the node roles it applies to and the reason for it. The baseline is then rolled out across nodes in the sequence you approve, with verification after each change. Verification typically means sending zero gas price transactions from accounts with and without balance, confirming that every node accepts and orders them, and recording the results. Your team should confirm the exact fork name, client version and transaction pool implementation before the baseline is written, since those change which settings apply.
Engagements are fixed scope. The scope, the list of nodes, the written deliverables and the timeline are agreed in writing before work starts, and no price is given on this page. Deliverables normally include the settings baseline, the configuration change record, the verification evidence and handover documentation for your operators. Ask for the scope document to name who is responsible for genesis changes that would require a network restart, and for how any later Besu upgrade will be checked against the baseline.
How DeployOpen works on this
DeployOpen plans and implements free gas settings as part of a self-hosted Besu network in infrastructure you control. We start from your written scope, build the node configuration across every validator and RPC node, test the zero gas behavior, and document the result so your operators can run it after handover.
How we scope
- Written scope lists every node role, validator and RPC node, that must carry the zero gas settings.
- We record which transactions must succeed at zero gas, such as contract deployments and token transfers.
- Scope states the London fork status and whether zeroBaseFee is enabled on all nodes.
How we build
- We set min-gas-price to zero on every node, then check each configuration file for drift.
- We configure block gas limit, contract size and the per-transaction gas cap to match your application needs.
- We test balance check behavior with zero-balance senders before any application traffic reaches the network.
How we hand over
- Deliverables include the node configuration files, a settings register and a short runbook for operators.
- We document why each free gas setting exists so future changes are reviewed against the same reasoning.
- Your team receives test scripts that confirm zero gas transactions are accepted across all nodes.
How we support
- Ongoing support is available as a retainer for configuration reviews after Besu release upgrades.
- Retainer work can cover re-testing gas settings when a new node joins or the genesis file changes.
- Fixed-scope engagements have quotes based on the written scope, so you know what each change costs.
