Environment:
Client: Dash Wallet (iOS)
Related sync: Dash Desktop Wallet (1.0.0-beta.2)
Network: Mainnet
Summary:
Initiated a shielded transfer from a Core-balance wallet with a large number of small UTXOs (masternode reward payouts). The L1 asset-lock transaction broadcast and confirmed successfully, but the follow-up Platform "Shield from Asset Lock" state transition failed with a size-limit error. Funds remain locked on-chain and inaccessible from both the iOS wallet and the desktop wallet.
Steps to reproduce:
Wallet held Core balance accumulated from frequent small masternode reward payouts, resulting in 83 separate UTXOs.
Initiated a shielded transfer for 64.42054427 Dash via the iOS Dash Wallet's new shielded transfer feature.
The wallet constructed and broadcast an asset-lock transaction consuming all 83 inputs (raw tx size: 12,340 bytes).
Asset-lock transaction confirmed on-chain (300+ confirmations at time of writing).
The subsequent "Shield from Asset Lock" state transition failed with:
shielded resume fund-from-asset-lock failed: SDK error: Dapi client error: transport error: grpc error: code: 'Client specified an invalid argument', message: "State Transition exceeds maximum size of 20480 bytes"
iOS wallet shows "Your Dash is safe — This transfer's funds were locked on-chain but the private transfer didn't finish. Tap Finish now to complete it." Tapping Finish repeats the same error.
Desktop wallet (synced to the same seed) shows the send as completed (-64.42054427 Dash) and Shielded balance as 0 Dash — no way to view or resume the pending asset lock from desktop.
Suspected root cause:
The asset-lock proof appears to embed the full raw L1 transaction. With 83 inputs, the raw transaction alone is 12,340 bytes; once wrapped in the Platform state transition (with Orchard bundle / proof overhead), total size exceeds the 20,480-byte state transition cap. This looks like an edge case triggered specifically by wallets with many small UTXOs (e.g. frequent masternode reward payouts), which the client doesn't currently guard against before attempting a shielded transfer.
Transaction details:
Asset-lock TXID: b7507ec880ae8c3a2f1de66b87826a1a348bd15a8cb14fca1575b290581dfb60
Asset-lock (OP_RETURN) output: 64.42042028 Dash
Change output (output 1): 0.00006366 Dash
Number of inputs: 83
Raw transaction size: 12,340 bytes
Amount debited from Core wallet: 64.42054427 Dash
Impact:
~$2,670 USD equivalent is currently locked on-chain with no path to completion via either the iOS or desktop client.
Requested help:
Confirmation that the locked value in this asset-lock output is recoverable (per DIP-0027, unused asset-lock value should remain available for future Create/TopUp/Shield transitions even after a failed state transition).
Guidance or tooling to manually complete or reclaim this asset lock, since the client-side retry deterministically fails on the same size limit.
A client-side fix to either split large-input transfers into multiple smaller asset locks, or warn users before attempting a shielded transfer from a wallet with a high UTXO count.
Environment:
Client: Dash Wallet (iOS)
Related sync: Dash Desktop Wallet (1.0.0-beta.2)
Network: Mainnet
Summary:
Initiated a shielded transfer from a Core-balance wallet with a large number of small UTXOs (masternode reward payouts). The L1 asset-lock transaction broadcast and confirmed successfully, but the follow-up Platform "Shield from Asset Lock" state transition failed with a size-limit error. Funds remain locked on-chain and inaccessible from both the iOS wallet and the desktop wallet.
Steps to reproduce:
Wallet held Core balance accumulated from frequent small masternode reward payouts, resulting in 83 separate UTXOs.
Initiated a shielded transfer for 64.42054427 Dash via the iOS Dash Wallet's new shielded transfer feature.
The wallet constructed and broadcast an asset-lock transaction consuming all 83 inputs (raw tx size: 12,340 bytes).
Asset-lock transaction confirmed on-chain (300+ confirmations at time of writing).
The subsequent "Shield from Asset Lock" state transition failed with:
shielded resume fund-from-asset-lock failed: SDK error: Dapi client error: transport error: grpc error: code: 'Client specified an invalid argument', message: "State Transition exceeds maximum size of 20480 bytes"
iOS wallet shows "Your Dash is safe — This transfer's funds were locked on-chain but the private transfer didn't finish. Tap Finish now to complete it." Tapping Finish repeats the same error.
Desktop wallet (synced to the same seed) shows the send as completed (-64.42054427 Dash) and Shielded balance as 0 Dash — no way to view or resume the pending asset lock from desktop.
Suspected root cause:
The asset-lock proof appears to embed the full raw L1 transaction. With 83 inputs, the raw transaction alone is 12,340 bytes; once wrapped in the Platform state transition (with Orchard bundle / proof overhead), total size exceeds the 20,480-byte state transition cap. This looks like an edge case triggered specifically by wallets with many small UTXOs (e.g. frequent masternode reward payouts), which the client doesn't currently guard against before attempting a shielded transfer.
Transaction details:
Asset-lock TXID: b7507ec880ae8c3a2f1de66b87826a1a348bd15a8cb14fca1575b290581dfb60
Asset-lock (OP_RETURN) output: 64.42042028 Dash
Change output (output 1): 0.00006366 Dash
Number of inputs: 83
Raw transaction size: 12,340 bytes
Amount debited from Core wallet: 64.42054427 Dash
Impact:
~$2,670 USD equivalent is currently locked on-chain with no path to completion via either the iOS or desktop client.
Requested help:
Confirmation that the locked value in this asset-lock output is recoverable (per DIP-0027, unused asset-lock value should remain available for future Create/TopUp/Shield transitions even after a failed state transition).
Guidance or tooling to manually complete or reclaim this asset lock, since the client-side retry deterministically fails on the same size limit.
A client-side fix to either split large-input transfers into multiple smaller asset locks, or warn users before attempting a shielded transfer from a wallet with a high UTXO count.