Scoutinternal

Staking, Unstaking, and Rewards Issues Across Supported Chains

Staking, Unstaking, and Rewards Issues Across Supported Chains

Problem

Customers encounter a range of issues when staking, unstaking, or viewing staking rewards on the BitGo platform. Common symptoms include: staking transactions failing with errors in the UI, staked balances not displaying correctly (funds appearing spendable when they should be locked, or staked amounts missing from the interface), rewards not accruing or not being visible in the wallet, unstaked funds not returning to the wallet after the expected unbonding period, validators not appearing in the staking dropdown, and the staking tab or stake button not being visible at all. These issues span multiple chains including ETH, SOL, DOT, STX, SUI, SEI, ATOM, CSPR, MATIC, AVAX, and ZETA, and can stem from platform bugs, chain-level protocol changes, indexer delays, validator API errors, UI regressions, licensing/geo-restrictions, or wallet configuration problems.

Diagnostics

  • Identify the coin and wallet: Obtain the Wallet ID, Enterprise ID, coin ticker, and base/root address from the customer. Look up the wallet in the TAT tool to confirm balances (Balance, Confirmed, Spendable) and enterprise configuration.
  • Check enterprise staking license: In the TAT tool, verify that the staking license is enabled for the enterprise. Also check if the enterprise is on testnet vs. mainnet — staking may need to be enabled separately for each environment.
  • Check geographic restrictions: Confirm the customer's jurisdiction. Some regions (e.g., Italy) are not supported for staking. If staking is unavailable, this may be the reason.
  • Verify wallet initialization: For chains like SOL, the wallet must be chain-initialized (funded with a minimum deposit) before staking can proceed. Check if the wallet shows "Pending Chain Initialization."
  • Review transaction/transfer history: Look at the Staking tab within the wallet and the Activity/Pending Approvals tabs. Check for pending approvals, failed transactions, or "Error" states. Note any transfer IDs or tx hashes the customer provides.
  • Check for known platform incidents: Review the BitGo status page (https://status.bitgo.com/) and internal Slack channels (e.g., #alt-team, #staking) for any ongoing chain-specific indexer delays, hardfork impacts, or known bugs.
  • Inspect the send queue and on-chain status: Use internal tools to query the send queue state for any relevant transaction. Cross-reference on-chain using the appropriate block explorer (e.g., Etherscan, Solscan, Subscan, beaconcha.in, Mintscan, cspr.live).
  • Compare UI views: If the customer reports missing delegations or balances in the new UI, ask them to check the Legacy UI (accessible via Profile button → switch to Legacy/Classic view) to determine if it is a new-UI-specific rendering issue.
  • Check for protocol/breaking changes: For chains like DOT and STX, recent protocol upgrades (e.g., DOT removing the controller from bond calls, STX pox-2 → pox-3 upgrade) can cause staking failures. Verify with engineering if relevant.
  • Review validator availability: If the customer sees "No partner validators," check for known bugs in the validator list or whether the coin's staking validators were temporarily removed from the UI.

Resolution

Scenario: staking-stake-rewards-unstake#staking-tx-failure-engineering

Trigger: Customer initiates a staking transaction from the UI or API and receives a "Transaction Failed" error, with no clear user-side misconfiguration.

Signals: transaction failed, staking failed, error, DOT staking, ETH staking, SOL staking, CSPR staking, ZETA unstaking, failed to execute message, invalid shares amount

Steps:

  1. Collect the Wallet ID, coin, Enterprise ID, and any tx hash or transfer ID from the customer.
  2. Look up the transaction in the send queue using internal tools. Check the state field and any associated error messages.
  3. Check internal Slack channels and JIRA for known issues with the specific chain's staking (e.g., CR-1218 for ZETA, DOT breaking changes, Blockdaemon API errors for ETH).
  4. If a known platform or chain issue is identified, create a JIRA ticket (if one does not exist) and escalate to the engineering team.
  5. Inform the customer that the issue has been referred to engineering and provide updates as they become available.
  6. Once engineering confirms a fix, ask the customer to retry the staking transaction. For ETH, engineering may need to increase the gas upper limit in the configuration for the validator before the customer retries.
  7. If the failure was caused by a third-party validator provisioning API (e.g., Blockdaemon), confirm with the vendor that the issue is resolved before asking the customer to resubmit.

Notes: DOT staking failures have been linked to a breaking change where the DOT network removed the controller from the bond call. ETH staking failures have been caused by gas limit configuration being too low for the validator. ZETA unstaking failures have been linked to balance indexing issues (e.g., "invalid shares amount: invalid request"). CSPR staking errors were resolved under CR-901. SOL staking failures have required engineering JIRA investigation. After a fix is deployed, the customer should clear their browser cache before retrying.

"Our engineering team is requesting you retry this request. Gas with ETH fluctuates greatly. We increased the upper limit set in the configuration for 1 validator which should allow this to move forward." "The DOT network introduced a breaking change to their network. They removed controller from the bond call and it is no longer needed to build a staking transaction. Changes need to be made on our end to not use the controller call since that is what is still being used on our staking calls by default." "We found out that the API that we use to provision Blockdaemon validators was throwing an error and why the transactions just failed again. Blockdaemon just worked with us to fix the problem, please note that this was not an issue on the BitGo side this time around."

Scenario: staking-stake-rewards-unstake#balance-display-mismatch

Trigger: Customer reports that staked funds still appear as spendable in the wallet, or that the staking balance shown in the UI does not match the on-chain state.

Signals: balance mismatch, funds not locked, spendable balance incorrect, staked amount wrong, undelegated early, STX balance showing available, SOL reconciliation, DOT staking amount difference

Steps:

  1. Collect the Wallet ID, coin, and any relevant transaction hashes or screenshots.
  2. Verify the on-chain staked balance using the appropriate block explorer and compare to what BitGo shows (Balance, Confirmed, Spendable in TAT tool).
  3. If the on-chain state confirms funds are staked but BitGo shows them as spendable, escalate to engineering as a balance indexing bug.
  4. For STX specifically: confirm with the validator (e.g., Chorus One) whether the delegation is active. A bug has been observed where BitGo incorrectly shows a deposit (undelegation) in the transaction history when funds are actually still locked. Engineering can remove the erroneous deposit entry and correct the wallet balance.
  5. For DOT: the UI may show a higher requested staking amount than what was actually bonded on-chain. This occurs because not all balances were eligible for bond_extra at the time of the transaction. The actual on-chain bond_extra or max_additional amount is the correct figure. Engineering has acknowledged this as a UI feature request.
  6. For SOL: the staking tab may show stale delegations after unstaking. Engineering may need to fail old pending requests and have the customer sign a claim request to reconcile.
  7. Inform the customer of the discrepancy and provide engineering's timeline for the fix.

Notes: For STX, 0-value transfers appearing as deposits in the wallet are delegate-stack-extend transactions from the validator extending the delegation lock. They do not affect the wallet balance. For DOT, BitGo deducts a reserved amount (~20 DOT) for staking fees which is not spendable, so the displayed staked amount may differ from the requested amount.

"There was a bug on our end which showed the below deposit in error. The funds were not undelegated. This deposit entry has now been removed and wallet balances are accurately reflecting the onchain balance." "The validator sends a transaction to extend the delegation lock by increasing the unlock height. The 0-value transfer showing a deposit is a delegate-stack-extend transaction. It doesn't affect the wallet, it's recorded to keep track of the lock extension." "The transaction details and onchain amount are correct. The 3625.4962789835 DOT and 8900 DOT are the intended bond_extra amounts or max_additional amount. However, not all the balances were eligible for bond_extra at that time."

Scenario: staking-stake-rewards-unstake#rewards-not-visible

Trigger: Customer reports that staking rewards show as 0 or are not updating, despite on-chain evidence of accrued rewards.

Signals: rewards not visible, lifetime rewards 0, staking rewards stopped, no rewards, SEI rewards, ETH rewards, cronjob

Steps:

  1. Collect the Wallet ID, coin, Enterprise ID, and any block explorer links showing accrued rewards.
  2. Check the Staking tab in the wallet for the "Lifetime Rewards" figure and compare to on-chain data.
  3. If rewards are confirmed on-chain but not reflected in BitGo, escalate to engineering.
  4. For ETH: rewards may stop updating if an internal cronjob stops running. Engineering can restart the cronjob, after which a large batch of rewards may arrive at once. Direct the customer to check using beaconcha.in for validator-level reward tracking.
  5. For SEI: a platform bug has caused rewards to show as 0 despite being accrued on-chain. Engineering deployed a fix; ask the customer to verify after the fix is confirmed.
  6. For SEI specifically: rewards must be claimed via unstaking — rewards are credited to the wallet instantly upon unstake, but the staked principal has a 21-day cooldown period.
  7. For viewing daily rewards via API, direct the customer to the endpoint documented at: https://developers.bitgo.com/guides/wallets/staking/view-rewards. Note that as of the ticket evidence, the UI only shows a lifetime total, not daily breakdowns.

Notes: ETH consensus rewards "drip" — if the staked balance exceeds 32 ETH, anything above 32 enters the exit queue (6-8 days), so rewards drip over time. ETH execution rewards land on-chain directly to the wallet and increase the spendable balance. ETH unstaking shows as 0 value in line item exports since nothing is technically broadcast from BitGo, but balances adjust accordingly. There may be minor differences between the reward-accrual-report API endpoint and the transfers endpoint due to timing of how each tracks rewards.

"We received a large chunk of rewards at once when you guys kickstarted the cronjob again." "Calling the following API endpoint will be the best way to keep up daily with reward accrual for your Staking: https://developers.bitgo.com/guides/wallets/staking/view-rewards. Currently, there is no visibility into this from within the UI." "You need to unstake your rewards before you can withdraw them. To unstake, select the Unstake button. For SEI, rewards will be credited to the wallet instantly but staked amount will be credited after 21 days of cool down period."

Scenario: staking-stake-rewards-unstake#unstaked-funds-not-returned

Trigger: Customer unstaked funds but they have not appeared in the wallet after the expected unbonding/withdrawal period.

Signals: unstaked ETH not received, unstaking not complete, withdrawal queue, unbonding period, SOL unstaking, ETH unstaking

Steps:

  1. Collect the Wallet ID, coin, unstaking request ID or tx hash, and the date the unstake was initiated.
  2. Check the on-chain status of the unstaking transaction using the appropriate explorer.
  3. For ETH: after unstaking, the validator must exit the exit queue and then enter the withdrawal queue. This process can take 2-6 days total (sometimes up to 14-16 days). While exiting, the validator is still accruing rewards and the position may still show as staked in the UI. Use beaconcha.in to check the validator's withdrawal status.
  4. For SOL: unstaking involves two transactions (deactivate and withdraw). During the deactivating phase, the customer is still earning rewards, so the final withdrawn amount may be slightly larger than the first transaction's amount. A rent amount of 0.00228288 SOL cannot be unstaked and will remain in the delegation. If the validator still appears in the unstaking list after full unstake, this is expected behavior due to the rent reserve.
  5. If the unbonding period has clearly passed and funds have not returned, escalate to engineering with the wallet ID and unstaking request details.
  6. For SOL, engineering may need to manually process the claim step or reconcile stale delegation records.

Notes: For MATIC (ERC-20): the wallet enters a cooldown period after unstaking. Until the cooldown is over, you cannot interact with the staking for that wallet (including initiating new unstaking). For ETH: the UI shows a "pending" balance to denote how many validators are being unstaked — this is expected while exiting.

"For SOL, during the deactivating phase, you are still earning a bit of rewards. When you withdraw, it withdraws everything hence the delta. ... we keep the rent in the delegation 0.00228288, this cannot be unstaked which is why it still shows there." "This unstake should appear within your wallet within the next day or so. We show this unstake has exited and should now be in the withdrawal queue which can take 2 to 3 days to complete."

Scenario: staking-stake-rewards-unstake#no-validators-or-staking-tab-missing

Trigger: Customer cannot see the staking tab, the stake button is greyed out, or the validator dropdown shows "No partner validators."

Signals: no validators, staking tab missing, no partner validators, stake button greyed out, staking not enabled, SUI validators, activate staking, Get Started

Steps:

  1. Check the TAT tool to verify whether the staking license is enabled for the customer's enterprise and environment (production vs. testnet).
  2. If the staking license is not enabled, enable it in the TAT tool for the correct enterprise and environment. Ask the customer to close their current session and log in again (or clear browser cache) for the change to take effect.
  3. If the staking license is enabled but the staking tab is not visible, check geographic restrictions. If the customer is in a restricted jurisdiction (e.g., Italy), staking cannot be offered. Inform the customer that staking is not supported in their country.
  4. If the customer sees "No partner validators" (observed with SUI), check with engineering — this has been a known platform bug. The fix involves clearing the browser cache after the bug is resolved server-side.
  5. If the stake button or amount field is greyed out, escalate to engineering. This has been caused by backend provisioning issues (e.g., ETH staking configuration) that engineering resolved with a targeted fix.
  6. For wallets that have not been chain-initialized (e.g., SOL), the wallet must be funded with the minimum initialization amount before the staking tab will function. For SOL, deposit at least 0.002447136 SOL; the minimum to stake is 0.01 SOL.

Notes: When enabling staking on an enterprise, the customer must log out and log back in (or clear browser cache) for the staking tab to appear. On testnet, staking may need to be enabled separately from production. The "Get Started" link in the staking section of the UI initiates the staking enrollment process for an enterprise.

"We checked this is a bug on our platform which has already been fixed. Please clear your browser cache and try again. Let us know if you are still unable to stake." "Looks like Staking isn't enabled on your Enterprise. Please choose the 'Get Started' link in your first screenshot and follow the instructions to add Staking. What is the country you are located in? ... Staking isn't supported in Italy." "I noticed that the mentioned wallet does not have any balance and still Pending Chain Initialization. The first thing you need to do is deposit 0.002447136 SOL to the receive address of your wallet. ... the minimum to stake is 0.01 SOL thus you need to funds your wallet accordingly."

Scenario: staking-stake-rewards-unstake#staking-approvals-and-signing

Trigger: Customer submits a staking/unstaking transaction but approvers cannot see the pending approval, or the transaction is stuck in "Pending BitGo Approval" or "Pending Final Approval."

Signals: pending approval, pending BitGo approval, approvals not showing, staking approvals, bypass approvals, script, admin approval, Activity tab

Steps:

  1. Confirm the Wallet ID, Enterprise ID, and transaction/request IDs involved.
  2. Check the Activity tab and Pending Approvals tab in the UI. Note that in the new UI, staking actions were previously not appearing under the Activity tab (a known bug that was fixed — verify the customer is on the latest UI).
  3. If approvers cannot see pending approvals for staking transactions, this may require an engineering script to push pending approvals through. Escalate to engineering with the wallet ID and enterprise ID.
  4. If the customer requests that BitGo bypass pending admin approvals (e.g., for bulk staking), obtain explicit written confirmation via email from an authorized enterprise user stating: the Enterprise ID, Wallet ID, total amount to be staked, and permission to bypass pending admin approvals. Then escalate to engineering to run the bypass script.
  5. For custody (cold) wallets, after admin approvals are completed, the transaction enters "Pending BitGo Trust Approval" — this is signed by BitGo's Trust team during their next signing window. Inform the customer of the expected timeline.
  6. If the customer reports the transaction shows "Error" in the pending approvals list, ask them to try refreshing or using an incognito browser window. If the error persists, escalate to engineering.

Notes: In the new UI, a fix was deployed to show all staking actions under the Activity tab. Prior to this fix, staking/unstaking pending approvals were only visible in the legacy UI. Customers should switch to legacy UI as a workaround if the new UI does not display pending approvals.

"Rest assured we see them on our end too and it's expected that the pending approvals aren't showing up for the approvers right now until we push a script through which our engineering team is working on right now. Once this is completed, the pending approvals will show up as expected." "Our engineering team deployed a fix yesterday to show all staking actions under the activity tab, can you please verify that the raised issue is now resolved?"

Scenario: staking-stake-rewards-unstake#ui-display-bugs

Trigger: Customer reports visual issues in the staking UI — missing delegations, duplicate entries, gaps between rows, or delegations only visible in legacy UI.

Signals: visual bug, missing delegations, legacy UI, new UI, duplicate entries, gaps, staked SUI not displayed, SOL unstaking dropdown missing

Steps:

  1. Ask the customer to switch to the Legacy UI (Profile button → switch view) and check if the delegations are visible there.
  2. If delegations appear in legacy UI but not the new UI, this is a known new-UI rendering issue. Escalate to engineering with the Wallet ID and screenshots.
  3. For SUI: the unstaking modal may show the staked object ID instead of the validator address. In the Staking Tab, BitGo groups delegations by validator address. Clarify this distinction to the customer.
  4. For duplicate or gapped entries (observed with SUI), ask the customer to change the "rows per page" setting at the bottom of the page. If the issue persists, escalate to engineering.
  5. After engineering deploys a fix, ask the customer to clear their browser cache and verify.

Notes: The legacy UI can serve as a temporary workaround for new-UI-specific display issues. For SUI wallets with multiple staked objects per validator, the new UI may display them differently than expected.

"Please see attached, if I go to legacy UI, then I can find everything. There should be something wrong with the new UI for SOL." "Our engineering team took a look and report these wallets have 2 staked objects. What your team is seeing in unstaking modal is the staked object id not and the validator address. In the Staking Tab, we group by validator address for our platform."

Scenario: staking-stake-rewards-unstake#send-to-staking-wallet-whitelist

Trigger: Customer receives an error when trying to send funds from a Go Account to a staking wallet.

Signals: send error, staking wallet, whitelist, Go account, whitelisted address, video verification

Steps:

  1. Advise the customer to whitelist the recipient (staking wallet) address on their Go Account.
  2. Note that the first transaction to any newly whitelisted address — including internal BitGo wallet-to-wallet transfers — requires a video verification callback. This requirement cannot be waived.
  3. If the customer was unable to whitelist a BitGo staking wallet address on the Go Account, they may need to fund the staking wallet directly from an external source as a workaround.
  4. To delete or archive an unneeded wallet, navigate to the wallet's Settings and select the archive option.

Notes: For AVAX staking: funds must be in an AVAX P-chain wallet (address starts with "p-xxx"). The C-chain wallet must have the P-chain wallet whitelisted. Export from C-chain to P-chain is required before staking, and the C-chain wallet gas tank needs ~1-2 AVAX for export fees.

"You need to whitelist the recipient address on your Go Account." "For withdrawals requiring video, this is required for the first transaction to any newly whitelisted address, not matter if internal or external, between wallets or too the same wallet. It is not possible to waive this requirement."

Scenario: staking-stake-rewards-unstake#staking-reports-and-statements

Trigger: Customer requests staking reports, statements, or detailed reward breakdowns for auditing or accounting purposes.

Signals: staking statements, staking report, rewards report, audit, monthly report, download staking, accounting

Steps:

  1. For daily reward tracking, direct the customer to the staking rewards API endpoint: https://developers.bitgo.com/guides/wallets/staking/view-rewards. The UI currently shows only a lifetime total.
  2. For enterprise-level staking reports (rewards, delegated balance, staking transactions), support can pull reports via the API endpoint /api/staking/v1/{coin}/reward-accrual-report?enterpriseId={enterpriseId} with appropriate date ranges.
  3. For historical staking statements requested for audit purposes, support can generate and send reports per enterprise ID, per month. Reports typically include: Staking rewards, Delegated balance, and Staking transactions as separate files.
  4. If there is a discrepancy between the reward-accrual-report endpoint and the transfers endpoint, note that these two endpoints may track rewards with slightly different timing. Escalate to engineering if the discrepancy is significant.
  5. Inform the customer that there is currently no self-service UI option to download staking transaction listings, but this has been noted as a feature request.

Notes: ETH "Staking Withdrawal" entries in transaction history correspond to consensus income (rewards dripped from the beacon chain). These transaction hashes may not appear on Etherscan but can be verified on beaconcha.in. ETH execution rewards appear as on-chain deposits directly to the wallet. Unstaking entries may show as 0 value in line item exports since nothing is broadcast from BitGo.

"The unstaking will show up as 0, as nothing is technically broadcast from BitGo but balances will adjust accordingly." "Our engineering team reviewed these transactions and reports these are automatic staking withdrawals. Etherscan does not chart these, but using a beacon chain explorer can be used to review the transaction: https://beaconcha.in/address/..."

Scenario: staking-stake-rewards-unstake#chain-hardfork-or-protocol-change

Trigger: Staking or unstaking fails or behaves unexpectedly immediately after a chain upgrade, hardfork, or protocol change.

Signals: hardfork, protocol change, Pectra, pox-2, pox-3, breaking change, indexer update, ATOM hardfork, DOT controller removed

Steps:

  1. Check internal channels for any recent chain upgrades affecting the coin in question.
  2. For STX: confirm the validator has upgraded to the current PoX version (e.g., pox-3 after pox-2 deprecation). Ask the customer to verify with their validator.
  3. For DOT: the network removed the controller from the bond call. Engineering must update the staking calls to not use the controller. This requires a backend fix.
  4. For ATOM: hardforks may require BitGo indexers to be updated to the latest version. Engineering updates indexers to reach chainhead, after which the customer can retry.
  5. For ETH post-Pectra: as of the latest ticket evidence, migration to 0x02 credentials has not yet been implemented and is still in the research phase. New staking with Pectra features (e.g., up to 2,048 ETH per node) is not yet available.
  6. Inform the customer of the status and provide updates as engineering completes the necessary changes.

Notes: Protocol changes are a recurring cause of staking failures. Always check for recent chain upgrades when diagnosing sudden staking issues across multiple customers on the same chain.

"On STX, apologies the feedback on the STX staking is a little technical but there was a critical protocol change recently - pox-2 has been deprecated and has been upgraded to pox-3. Can you please confirm with your validator that they have upgraded to pox-3?" "Speaking with our engineering team, it appears this was caused by an ATOM Hardfork which required our indexers to be updated to the latest version. We should now be at chainhead with this issue full resolved." "Our engineering team has confirmed that this has not yet been migrated."

Related