Scoutinternal

Transaction Fees, Gas Estimation, and Fee Clarification on BitGo

Transaction Fees, Gas Estimation, and Fee Clarification on BitGo

Problem

Customers frequently contact support with questions and issues related to transaction fees across multiple chains. Common concerns include: unexpectedly high network/miner fees (especially on ETH and BTC), confusion about BitGo's service fee versus blockchain network fees, difficulty using the fee estimation API (/api/v2/{coin}/tx/fee) for specific coins (DOT, DOGE, BTC), gas tank withdrawal requests for ETH, stuck transactions due to low gas prices, and questions about staking fee structures visible in the UI. These issues span UTXO-based chains (BTC, DOGE), account-based chains (ETH, DOT), and staking services.

Diagnostics

  • Identify which fee the customer is asking about: BitGo charges a fixed service fee of 0.025% of the amount sent. Network/miner fees are separate, fluctuate with blockchain congestion, and are not controlled by BitGo. Confirm which fee the customer is questioning.
  • Check current network conditions: For ETH, review https://etherscan.io/gastracker to verify if gas prices are elevated due to network congestion. For BTC, check mempool congestion via a block explorer.
  • Check the coin type: Fee estimation behavior differs between UTXO coins (BTC, DOGE, LTC) and account-based coins (ETH, DOT, Polygon). The API endpoint /api/v2/{coin}/tx/fee returns different fields depending on coin type.
  • For UTXO coins: The fee estimate endpoint returns feePerKb. The customer needs to multiply this by the transaction size (in KB/vBytes). Verify whether the customer is passing required parameters (e.g., numBlocks, nOuts/nOutputs).
  • For ETH-based coins: Check if the gas tank has sufficient ETH to cover fees. In the BitGo UI, navigate to the enterprise's "Gas Tanks" section and verify the balance of the ETH gas tank.
  • For DOT: The fee estimation endpoint historically required a tx (transaction hex) parameter. A fix was deployed so that setting just the coin may now suffice — confirm current behavior by testing.
  • For stuck/low-fee transactions: Check the transaction hash on a block explorer. Determine if the transaction is still pending in the mempool with a low gas price.
  • For staking fee questions: The staking fee shown in the UI applies only to assets staked through the BitGo UI to validators directly partnered with BitGo. It does not apply to assets staked externally before BitGo's staking-as-a-service offering. The fee thresholds are based on the value of assets staked, not the rewards earned.
  • For feeString confusion on BTC transfers: The feeString field in a Get Transfer response represents the total fee paid for the entire on-chain transaction (in satoshis), not just the customer's portion. A transaction with multiple entries may have a fee that appears disproportionately large relative to a single small output.

Resolution

Scenario: fee-fees-gas-transaction#high-eth-network-fees

Trigger: Customer reports unexpectedly high ETH network fees compared to other wallets or previous transactions.

Signals: ETH, high fee, gas, network fee, 0.05 eth, expensive, gas price

Steps:

  1. Check current ETH gas prices at https://etherscan.io/gastracker to confirm whether network congestion is elevated.
  2. Explain to the customer that ETH network fees fluctuate based on blockchain congestion and are not set by BitGo.
  3. If the customer is on Wallet Version 0, recommend upgrading to Wallet Version 1 or 2 for significant gas savings on wallet creation, address creation, and transactions.
  4. Recommend using sendMany for batching multiple transfers to reduce per-transfer gas costs.
  5. Point the customer to the ETH Fee Saving Techniques KB article for detailed cost comparisons.

Notes: BitGo's fee estimate is intentionally higher than the typical network fee to ensure transactions are processed quickly and do not fail. This is documented behavior.

"It seems that the current eth price is quite high https://etherscan.io/gastracker and is fluctuating a lot at the moment, which explains why you are seeing such a high varying amount." (ticket #218734)

Scenario: fee-fees-gas-transaction#bitgo-service-fee-vs-miner-fee

Trigger: Customer asks about increased sending fees or does not understand the fee breakdown.

Signals: sending fee, increase, fee structure, spammy, 0.025%, commission, BitGo fee, miner fee

Steps:

  1. Clarify that BitGo's service fee is fixed at 0.025% of the amount being sent.
  2. Explain that transaction/miner fees are separate, fluctuate with network conditions, and are not determined until the transaction reaches the blockchain.
  3. If the customer is seeing higher-than-expected miner fees, check current network congestion for the relevant chain.
  4. Provide the customer with links to the relevant block explorer or gas tracker for their chain.

Notes: This applies across all supported chains. The BitGo fee and the network miner fee are two distinct charges.

"Bitgo fee is fixed at .025% of the amount being sent. Transaction or miner fees will always fluctuate and are not determined until the transaction reaches the chain." (ticket #217965)

Scenario: fee-fees-gas-transaction#utxo-fee-estimation-api

Trigger: Customer is using the fee estimate API for a UTXO coin (BTC, DOGE) and cannot reconcile the feePerKb value with the actual transaction fee shown in the UI.

Signals: feePerKb, fee estimate, DOGE, BTC, transaction size, numBlocks, nOuts, calculate mining fee, sendMany, UTXO

Steps:

  1. Confirm the customer is calling GET /api/v2/{coin}/tx/fee with the numBlocks parameter.
  2. Explain that for UTXO coins, the endpoint returns feePerKb (fee per kilobyte). The actual fee is calculated as: estimate fee = feePerKb * transaction_size_in_KB.
  3. To estimate transaction size before sending, direct the customer to the Calculate Miner Fee Info endpoint: https://developers.bitgo.com/api/express.calculateminerfeeinfo
  4. For additional context on UTXO fee calculation, refer the customer to:
  5. Explain that the customer can use the Get Unspents endpoint to view wallet unspents and estimate how many inputs will be required, which affects transaction size.
  6. For DOGE specifically, note that BitGo has a hardcoded fee rate of 50,000,000 per KB. The customer can calculate: fee = 50,000,000 * transaction_size_in_KB.

Notes: The nOuts (or nOutputs) parameter is the only required parameter for the fee estimate call on some UTXO coins. The fee estimate provided by BitGo is intentionally higher than the usual network fee to ensure transactions process faster and do not fail.

"They are reporting we have a static fee for Doge. We have a hardcoded fee rate of 50,000,000 per kb." (ticket #277132)

"I believe you should be able to calculate size with https://developers.bitgo.com/api/express.calculateminerfeeinfo" (ticket #277132)

"For UTXO coins, please take a look at the fee section here https://developers.bitgo.com/coins/Bitcoin https://developer.bitcoin.org/devguide/transactions.html#transaction-fees-and-change For other account based coins, the fee returned will be in that coin smallest unit (base unit), to know the smallest units of the coin please refer to this page https://developers.bitgo.com/coins" (ticket #218887)

Scenario: fee-fees-gas-transaction#dot-fee-estimation

Trigger: Customer receives an error "must include at least one param: tx" when calling the fee estimation endpoint for DOT.

Signals: DOT, tdot, fee estimate, must include at least one param, tx parameter, Polkadot, Westend

Steps:

  1. The DOT fee estimate endpoint (/api/v2/{coin}/tx/fee) historically required a tx parameter containing the transaction hex.
  2. A fix was deployed so that the endpoint can return a fee estimate by just specifying the dot coin without the tx parameter. Ask the customer to re-test the endpoint.
  3. If the customer still needs to pass a tx parameter, they can use an older "dummy" transaction to get the current fee estimate.
  4. Confirm with the customer which testnet they are using — BitGo uses Westend for DOT testnet (tdot).
  5. If the issue persists after the fix, escalate to the altcoin engineering team for investigation.

Notes: The fix was deployed circa May 2023. BitGo's DOT testnet uses the Westend network.

"The fix was deployed and I was able to receive a response by just setting the dot coin. Can you please test it on your end as well and let me know if you are seeing any further issues?" (ticket #214963)

"For now, you can use an older 'dummy' transaction to get the current fee estimate." (ticket #214963)

Scenario: fee-fees-gas-transaction#btc-feestring-disproportionate

Trigger: Customer sees a feeString value in the Get Transfer API response that appears disproportionately large compared to the transfer value.

Signals: feeString, value, satoshis, tbtc, tbtc4, network fee, dust, transfer response, baseValue

Steps:

  1. Explain that the feeString field represents the total on-chain fee for the entire transaction, reported in the smallest unit (satoshis for BTC). This fee covers all inputs and outputs in the transaction, not just the customer's specific transfer.
  2. Note that BitGo's dust threshold is 2,750 satoshis. Any unspent below this amount is unusable. Sending very small amounts (near the dust threshold) will naturally result in fees that appear large relative to the transfer amount.
  3. Fee cost can also be inflated when covering the fee cost of unconfirmed unspents involved in the transaction.
  4. For testnet testing, recommend the customer move to TBTC4, which is a more stable testnet environment with fees more in line with the production chain. The faucet for TBTC4 is: https://testnet4.com/
  5. If the customer needs more detail, ask them to provide: the full endpoint URL as called, the payload, the email address of the access token creator, and the BitGo Express/SDK version.

Notes: This scenario commonly arises in testnet environments where fee rates can be disproportionately high relative to mainnet.

"Regarding feeString, yes this would be in Satoshis. For fee reduction, our engineering team is recommending you move to use TBTC4. This is a more stable testnet environment for test BTC with fees that are more in line with production chain." (ticket #233300)

"Of note, our dust threshold is 2750 Sats. Any unspent below this amount is unusable." (ticket #233300)

Scenario: fee-fees-gas-transaction#eth-gas-tank-withdrawal

Trigger: Customer requests withdrawal of remaining ETH from their enterprise gas tank to an external address.

Signals: gas tank, withdraw, ETH, sweep, gas fees, destination address

Steps:

  1. Confirm the customer's request to withdraw funds from the ETH gas tank, including the destination address.
  2. Perform the gas tank sweep using the internal tool: bga wallet recoverfromaddress [ADDRESS] --sweep
  3. If the sweep encounters an error, escalate to the engineering team to investigate and fix any backend issues before retrying.
  4. Once the sweep completes, provide the customer with the transaction ID and a link to the Etherscan confirmation (e.g., https://etherscan.io/tx/[TXID]).

Notes: Gas tank withdrawals may occasionally fail due to backend issues and require engineering intervention. Never send any coin/token besides ETH to the ETH Gas Tank.

"Apologies, while performing the gas tank withdrawal we ran into some issues and we have referred this issue to our engineering team. We complete the sweep as soon as our engineering team is fix the broken code in the backend." (ticket #67743)

Scenario: fee-fees-gas-transaction#stuck-low-gas-eth-transaction

Trigger: Customer reports an ETH transaction is stuck/pending due to a low gas price and requests a gas price bump.

Signals: bump, gas price, low gas, stuck, pending, ETH transaction, speed up

Steps:

  1. Obtain the transaction hash from the customer and verify the transaction status on Etherscan.
  2. Confirm the transaction is still pending in the mempool with a gas price below the current network minimum.
  3. Escalate to the engineering team to perform a gas price bump (replace-by-fee or nonce replacement) for the stuck transaction.
  4. Provide the customer with the new transaction hash once the replacement is broadcast and confirmed.

Notes: Gas price bumps require engineering intervention and cannot be performed via the standard UI or API by the customer.

Scenario: fee-fees-gas-transaction#staking-fee-clarification

Trigger: Customer sees an additional fee schedule in the BitGo UI for staking and asks whether it applies to them.

Signals: staking fee, commission, validator, rewards, thresholds, negotiable, staking as a service

Steps:

  1. Clarify that the staking fee shown in the UI is only applicable to assets staked through the BitGo UI to validators directly partnered with BitGo.
  2. If the customer previously staked assets (e.g., CSPR) before BitGo offered staking-as-a-service, those assets do not apply to this fee structure.
  3. Explain that the fee thresholds are based on the total value of assets staked, not the rewards earned.
  4. Confirm that these staking fee rates are non-negotiable.
  5. For questions about how the fee is deducted (from balance vs. invoice), escalate internally for clarification as this may vary.

Notes: The staking fee is separate from and in addition to any commission charged by the validator itself.

"The staking fee you see is only applicable to assets staked through the UI to validators that are directly partnered with BitGo. We understand your team is staking other assets like CSPR which was done before we had staking as a service. Those assets you've previously staked do not apply to this fee structure." (ticket #219792)

"The thresholds are for the value of assets staked, not the rewards." (ticket #219792)

"These rates are non-negotiable." (ticket #219792)

Scenario: fee-fees-gas-transaction#eth-fee-estimate-api-parameters

Trigger: Customer is using the fee estimate API for ETH and needs to refine the estimate with additional parameters.

Signals: ETH, fee estimate, recipient, data, amount, base units, gas estimate, API

Steps:

  1. For ETH, the fee estimate endpoint supports additional parameters for more precise estimation:
    • recipient (string): Recipient of the transaction
    • data (string): ETH data of the transaction
    • amount (string): Amount in base units being sent
  2. These parameters are ETH-only and can be passed to /api/v2/{coin}/tx/fee to improve the accuracy of the estimate.
  3. For account-based coins generally, the fee returned by the endpoint will be in the coin's smallest unit (base unit). Refer the customer to https://developers.bitgo.com/coins for base unit information.

Notes: These additional parameters are only applicable to ETH and ETH-like chains, not UTXO coins.

Related