bug(zk): corrupted credits not balanced error after block execution during shielded operations

[lklimek]

Description

During testing of shielded operations (shield from core, shielded transfers) on testnet, the Drive ABCI process produced a fatal "credits not balanced" error that halted block execution.

Error

2026-03-26T19:40:45.285834626Z ERROR abci client returned error
  client_id=DEFAULT:*abciclient.socketClient(tcp://drive_abci:26658)
  err="execution: corrupted credits not balanced error: credits are not balanced after block execution
    TotalCreditsBalance {
      total_credits_in_platform: 108181924240088,
      total_in_pools: 5075231436,
      total_identity_balances: 102946594130212,
      total_specialized_balances: 0,
      total_in_addresses: 5230254878442
    }
    off by 2"

Analysis

The credits mismatch is exactly 2 credits — total_in_pools + total_identity_balances + total_specialized_balances + total_in_addresses = 108181924240090 vs total_credits_in_platform = 108181924240088.

This suggests a rounding or double-counting issue in the shielded fee/credit accounting rather than a large-scale corruption.

Context

• Network: Testnet
• Operations: Repeated shield-from-core (Type 18) and shielded transfer (Type 16) state transitions
• Client: Dash Evo Tool v1.0-dev
• Date: 2026-03-26

Impact

This error halts block production on the affected node, requiring a restart or rollback.

_{🤖 Co-authored by Claudius the Magnificent AI Agent}

[lklimek]

https://dashpay.slack.com/files/U02CL50V0LW/F0AP556M7C2/unbalanced.log.zip

[QuantumExplorer]

I traced this locally and I think I found the likely root cause of the exact off by 2 imbalance.

This does not look like fee rounding. It looks like recent shielded nullifier metadata is being counted as credits.

What seems to be happening:

• AddressBalances is a top-level SumTree.
• The shielded credit pool lives under AddressBalances.
• Recent nullifiers are stored under the shielded pool in a CountSumTree (SHIELDED_RECENT_NULLIFIERS_KEY_U8).
• Each per-block recent-nullifier entry is written as an ItemWithSumItem, where the sum value is nullifiers.len().
• The end-of-block corruption check reads the aggregate sum of the entire AddressBalances tree as if it were credits.

Relevant code paths:

• packages/rs-drive/src/drive/initialization/v3/mod.rs
  • AddressBalances is initialized as a SumTree
  • recent nullifiers are initialized as a CountSumTree under the shielded pool
• packages/rs-drive/src/drive/shielded/nullifiers/store_nullifiers/v0/mod.rs
  • stores recent nullifiers as Element::new_item_with_sum_item(serialized, entry_count)
  • entry_count is the number of nullifiers for that block
• packages/rs-drive/src/drive/balances/calculate_total_credits_balance/v1/mod.rs
  • total_in_addresses is computed from the full AddressBalances sum tree
• packages/rs-drive/src/util/grove_operations/grove_get_sum_tree_total_value/v0/mod.rs
  • reads the raw sum-tree aggregate directly

Why this matches the issue exactly:

• if a block produces 2 recent nullifiers, the AddressBalances aggregate is inflated by 2
• the reported mismatch is exactly off by 2
• that is consistent with one shielded spend block creating two tracked nullifiers (or an equivalent recent-nullifier count of 2)

This should affect transitions that call the shared nullifier insertion path, not just shield-from-core flows:

• ShieldedTransfer
• Unshield
• ShieldedWithdrawal

ShieldFromAssetLock itself should not be the direct source, because it creates notes but does not insert spent nullifiers.

One more detail that supports this: when recent nullifiers are compacted, the old CountSumTree entries are deleted and replaced with plain Items in the compacted storage, which suggests the bad accounting is specifically in the temporary recent-nullifier storage.

So the likely fix is to keep recent nullifier sync metadata out of any credit-bearing sum tree, or at minimum stop assigning the nullifier count as a sum value in that subtree.

I did not reproduce the exact testnet block sequence from the attached logs, but the code path above matches the reported symptom very closely.