The max-fee-exceeded error in Bitcoin Core means a transaction exceeds the maximum fee-rate check being applied. It does not automatically mean the fee is too low or that waiting for another block will fix it. Before changing a parameter, reconcile units, input amounts, outputs and change.
The short answer is that maxfeerate is a safety ceiling, not the fee assigned to a transaction. Raising the ceiling cannot repair a wrongly constructed payment. It can merely allow a transaction whose rate was previously rejected. This guide addresses a specific RPC problem and does not replace reviewing the wallet’s transaction details.
What max-fee-exceeded actually tells you
The testmempoolaccept documentation describes a mempool acceptance check that can report a rejection reason. Its client-selected maximum is separate from both consensus validity and the economic decision about how much you intend to pay.
This article uses the Bitcoin Core 30.0.0 RPC reference, not an assumption that every provider exposes the same environment. For another release, hosted node or library, consult the actual help and complete response. An interface may summarize an error while hiding which component applied the limit.
Keep the method name, non-sensitive parameters and returned message when investigating. Do not publish RPC credentials, seeds, keys or unbroadcast signed transactions. A useful support report can often use version information and reconstructed test values rather than real wallet material.
maxfeerate does not rewrite the paid fee
The sendrawtransaction reference separates the limit from the transaction being submitted. A constructed and signed transaction already specifies inputs and outputs. Passing a different maximum to a submission call does not rebuild their economic difference.
Think of an alarm and the fault it reports. Moving the alarm threshold leaves a construction mistake intact. Changing the actual fee may require returning to the construction process and signing a corrected version, with all appropriate checks. An RPC parameter is not a repair tool for every stage.
Disabling the maximum should not be the standard response. The ability to bypass a check does not establish that the amount is intentional. If you cannot independently reconstruct the fee, stop instead of searching for a sufficiently large number that makes the warning disappear.
Convert BTC/kvB and sat/vB correctly
The referenced maximum is expressed in BTC per kilovirtual byte. Many wallet screens instead display satoshis per virtual byte. Divide a sat/vB rate by 100,000 to obtain BTC/kvB; multiply BTC/kvB by 100,000 for the reverse conversion. A different-looking number can describe the same rate in different units.
| Rate in sat/vB | Equivalent BTC/kvB |
|---|---|
| 1 | 0.00001000 |
| 5 | 0.00005000 |
| 10 | 0.00010000 |
| 25 | 0.00025000 |
This is an arithmetic conversion table, not a recommendation for today’s fees or a confirmation guarantee. For the broader mechanics, see our Bitcoin transaction-fee guide. The specific issue here is avoiding a comparison between values with different units.
For example, copying “10” from a wallet’s 10 sat/vB display into a field expecting BTC/kvB is a unit mistake. Write the unit beside each value before submitting a request. A short variable name in an application is not reliable evidence of what the receiving RPC expects.
A worked fee and change example
Use invented amounts: total inputs of 100,000 satoshis, a recipient output of 70,000 and change of 28,000. The fee is 2,000 satoshis, since 100,000 minus 70,000 minus 28,000 equals 2,000. At a final virtual size of 200 vB, this is 10 sat/vB.
If the change output is omitted and only the 70,000 output remains, the difference becomes 30,000 satoshis. Keeping a hypothetical 200 vB size for illustration gives 150 sat/vB. In a real transaction, removing an output also changes size, so the final size must be recalculated rather than reused blindly.
This does not claim that 150 sat/vB exceeds Core’s default ceiling. It shows that missing change can alter cost whether or not an automatic limit triggers. Identify the ceiling used in your case separately. Our Bitcoin UTXO explanation describes why transactions consume whole previous outputs and create change.
Checks to complete before broadcasting
- Identify the network, node or provider and actual software version.
- Find the method returning the rejection and the maximum it applies.
- Recover the amounts of the previous outputs consumed by the inputs.
- Review recipient addresses, values and the new change output.
- Calculate total fee and rate using the appropriate virtual size.
- Compare the result with both the intended budget and the ceiling in the same unit.
Decoding a transaction reveals structure and size, but does not magically retrieve every previous output’s amount. Referring to an input is not the same as knowing its value. If the required amounts are unavailable, the fee calculation is incomplete.
For PSBT workflows, analyzepsbt can provide information and estimates when the necessary data is present. An estimated size is not an already verified final measurement. Repeat relevant checks on the result actually intended for submission.
Start with help commands that do not send payments
The local help is a useful starting point in your configured environment. These commands consult documentation: they do not construct, sign or broadcast a payment. They assume an installed and reachable node. No password or private key needs to be inserted into a public example.
bitcoin-cli help testmempoolaccept
bitcoin-cli help decoderawtransaction
bitcoin-cli help analyzepsbtReal transaction data still requires privacy precautions. A valid signed transaction contains an executable spending authorization; do not upload it to random websites for a fee calculation. Practice in a separate test environment with valueless data rather than copying production credentials into a tutorial setup.
Acceptance testing is not confirmation
A local test reflects that node’s state and rules at the time. It does not establish acceptance by every peer, actual transmission or inclusion by a miner within a deadline. Testing, broadcasting and confirmation are distinct events with different evidence.
Some testmempoolaccept response fields can be absent when a transaction was rejected or not fully evaluated. Do not design an application on the assumption that every response always contains every field. Interpret the outcome first, then inspect available data. An absent number is not a zero.
A transaction already circulating with an insufficient fee presents a different problem. RBF and CPFP have their own requirements and do not cure every RPC error. Establish which transaction version has actually been transmitted before switching to a replacement or child-transaction workflow.
Similar-looking errors need different investigations
A minimum-fee rejection concerns too little relative to its check; max-fee-exceeded concerns a maximum. Missing inputs requires investigating availability of previous outputs. A decoding failure concerns the serialized format. Raising maxfeerate does not automatically solve these different problems.
maxburnamount is a separate parameter concerning certain recognized unspendable outputs, not the transaction-fee budget. Do not increase it to fix a fee issue. A protection based on certain output forms also cannot certify that every other address or script is spendable by the intended recipient.
A useful diagnostic record
With a hosted service, also ask where the response originated: Core itself, a gateway or application code. A provider can apply its own policy or transform a message before displaying it. Identifying that layer prevents changing a local configuration that does not participate in the request. Do not assume a value found in an unrelated tutorial describes your provider.
Before changing an integration, build a case with known amounts and check conversion separately from input-output accounting. Use a numeric representation that avoids accidental rounding. The test should reject an incorrect unit, not merely accept the correct example. This is a software-quality criterion, not an instruction to broadcast real payments by trial and error.
Record the exact transaction identity privately, the node version, the relevant limit and the calculated values with units. Compare the intended payment and change against the final outputs. This gives a reviewer an explanation of the failure instead of a screenshot containing only a short error label.
For the numerical example, keep total fee and rate side by side. A correct rate does not independently prove an acceptable total cost if the transaction is very large. Conversely, a small total amount does not establish that every output belongs to the intended recipient. Review both the accounting and the destination.
Frequently asked questions
Will waiting solve the error?
Not when the same serialized transaction exceeds the same ceiling. Time cannot recreate change or repair a unit conversion. Network conditions can evolve, but first identify the actual check that produced the response rather than assuming every rejection is congestion.
Should I raise the transaction fee?
Not as a response to this particular message. Reconstruct the cost already embedded in the transaction. Confusing an exceeded maximum with an insufficient minimum can lead to changing the transaction in precisely the wrong direction.
Is there a safe universal maximum?
No single value should be copied as a solution for every transaction. The ceiling is a protective choice to compare with verified values and units, not a market recommendation. Your version’s documentation and the provider’s conditions remain the operational references.
Does rejection prove nothing was broadcast?
It does not reconstruct the entire history. If another call or service already broadcast the same transaction, a later rejection does not undo that transmission. Check the transaction identity and workflow state before concluding that no submission occurred anywhere.
A sound response to max-fee-exceeded starts with correct data rather than bypasses: reconciled amounts, explicit units and an intentional ceiling. If any part remains unclear, pause submission and resolve it. Removing an error message is not evidence that the underlying payment is correct.
