You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Confirmed at height 237606 (237606 % 150 = 6 — well inside the window)
getrawtransaction verified "in_active_chain": true at that height across 8 checks spanning ~90 minutes, through window close (height 237682+). Never reorged.
The target finalizer's roster amount (get_tfl_roster_zec) over the same period moved only by the normal reward drip. The +10,000 never arrived — not during the window, not after it closed.
GUI wallet agrees: staked balance shows reward drip only; meanwhile the staked amount left the spendable balance. User impact: the funds are stranded in an unaccounted state — deducted from balance, never counted as bonded.
So the transaction layer accepted, mined, and finalized the stake, and the BFT/bond accounting layer never registered it.
Bug B: stake txs orphaned by reorg are never re-broadcast (silent stake failure)
An earlier 10,000 cTAZ stake (same wallet, previous window) was mined into a block that lost a reorg:
GUI reported the stake landed at height 237111 in block 000d969ff840dad0cbbac8952c7848d9636db583ba53276c4a225465a9779894
That block lost: getblock <hash> → "block height not in best chain"; both public explorers have no such block/tx
The winning block at 237111 contains only a coinbase and one unrelated 2-action orchard tx (valueBalanceZat: 10000 — far too small to be the stake)
The wallet never returned the tx to the mempool and never re-broadcast it. getrawtransaction → "No such mempool or main chain transaction". The stake silently failed; funds eventually reappeared as spendable.
Given this devnet's high fork/reorg churn plus the narrow 70-block staking window, "stake mined on the losing branch → gone forever" is a common path, and it happens with zero user-visible error. Suspect this explains some of the "malformed staking transaction" reports circulating in the community chat.
The zebrad log shows this repeating every few seconds, indefinitely (hundreds of occurrences over hours):
tx build error: can't afford 1000020000; only 1000000000 available from given sources
Shortfall is exactly 20,000 zats — the ZIP-317 fee. The builder selects notes summing to precisely the send amount (10 cTAZ), fails on fee headroom, then retries the identical selection forever. No backoff, no widened selection, no user-visible error. Timing suggests the auto-shield path (fires around each mined block on a mining-active wallet).
Bug D (UX, but actively misleading): "sidechain" label is wrong for canonically confirmed txs
The GUI labels the Bug-A stake "Staked @ 237653" with a sidechain tag — while getrawtransaction proves the same tx canonical at 237606 (label persisted across the whole observation period). 237653 was a fork-storm height at which this node mined several competing blocks; the label appears to track a last-seen block rather than the tx's actual canonical status. Consequence: users see "sidechain" on stakes that in fact confirmed — and (per Bug B) see nothing alarming when a stake actually did die. The two failure modes are labeled backwards.
Reproduction protocol used (all via RPC against the local node)
Snapshot getrawmempool before clicking Stake; diff after to capture the stake txid
Immediately save the raw hex (getrawtransaction <txid> 0) as re-broadcast insurance
Poll getrawtransaction <txid> 1 → in_active_chain/height through and past the window
Compare get_tfl_roster_zec target-finalizer amount before/after (reward drip ≈ +30/interval is the baseline signal; a 10k bond is unmistakable)
Happy to provide fuller logs, run diagnostics, or test candidate fixes on this node — it reproduces reliably here.
Environment
viz_gui, plus PR wallet persistence #29 (wallet snapshot) and PR Visualizer: clamp acknowledgement to chain tip #42 (viz ack clamp)wallet_staking_actionpostdates the tag)Bug A (primary): canonically confirmed staking transaction never credits the bond
A 10,000 cTAZ stake to an active finalizer was submitted early in a Staking Day window and confirmed on the canonical chain — the bond never appeared.
1f1dac08d18d01a885d80373b2165cc37e40f6ea8cb1b08a499de00630e446dbgetrawtransactionverified"in_active_chain": trueat that height across 8 checks spanning ~90 minutes, through window close (height 237682+). Never reorged.get_tfl_roster_zec) over the same period moved only by the normal reward drip. The +10,000 never arrived — not during the window, not after it closed.So the transaction layer accepted, mined, and finalized the stake, and the BFT/bond accounting layer never registered it.
Bug B: stake txs orphaned by reorg are never re-broadcast (silent stake failure)
An earlier 10,000 cTAZ stake (same wallet, previous window) was mined into a block that lost a reorg:
000d969ff840dad0cbbac8952c7848d9636db583ba53276c4a225465a9779894getblock <hash>→"block height not in best chain"; both public explorers have no such block/txvalueBalanceZat: 10000— far too small to be the stake)getrawtransaction→"No such mempool or main chain transaction". The stake silently failed; funds eventually reappeared as spendable.Given this devnet's high fork/reorg churn plus the narrow 70-block staking window, "stake mined on the losing branch → gone forever" is a common path, and it happens with zero user-visible error. Suspect this explains some of the "malformed staking transaction" reports circulating in the community chat.
Bug C: wallet tx-builder infinite retry loop on exact-value note selection (fee shortfall)
The zebrad log shows this repeating every few seconds, indefinitely (hundreds of occurrences over hours):
Shortfall is exactly 20,000 zats — the ZIP-317 fee. The builder selects notes summing to precisely the send amount (10 cTAZ), fails on fee headroom, then retries the identical selection forever. No backoff, no widened selection, no user-visible error. Timing suggests the auto-shield path (fires around each mined block on a mining-active wallet).
Bug D (UX, but actively misleading): "sidechain" label is wrong for canonically confirmed txs
The GUI labels the Bug-A stake "Staked @ 237653" with a sidechain tag — while
getrawtransactionproves the same tx canonical at 237606 (label persisted across the whole observation period). 237653 was a fork-storm height at which this node mined several competing blocks; the label appears to track a last-seen block rather than the tx's actual canonical status. Consequence: users see "sidechain" on stakes that in fact confirmed — and (per Bug B) see nothing alarming when a stake actually did die. The two failure modes are labeled backwards.Reproduction protocol used (all via RPC against the local node)
getrawmempoolbefore clicking Stake; diff after to capture the stake txidgetrawtransaction <txid> 0) as re-broadcast insurancegetrawtransaction <txid> 1→in_active_chain/heightthrough and past the windowget_tfl_roster_zectarget-finalizer amount before/after (reward drip ≈ +30/interval is the baseline signal; a 10k bond is unmistakable)Happy to provide fuller logs, run diagnostics, or test candidate fixes on this node — it reproduces reliably here.
Related