bug(zk): Shielded unshield rejected as "Tx too large" when spending many notes

[lklimek]

Summary

Unshielding the full shielded balance fails with "Tx too large" when the balance is spread across many small notes from prior shield operations. The Type 17 UnshieldCredits state transition bundles all input notes (each with an Orchard spend proof), exceeding Platform's transaction size limit.

Reproduction

1. Shield credits in multiple small operations (e.g., 10× 0.1 DASH)
2. Attempt to unshield the full accumulated balance (~1 DASH) to a platform address
3. Platform rejects:

NoAvailableAddressesToRetry(Grpc(Status {
    code: Internal,
    message: "Tx too large",
    metadata: { "drive-error-data-bin": "...", "code": "-32001" }
}))

Expected Behavior

Either:

• The SDK builder enforces the size limit pre-broadcast and returns a structured error with guidance (e.g., "Too many input notes — try a smaller amount")
• The SDK automatically splits large unshields into multiple smaller transitions
• The size limit is documented so client apps can pre-validate

Root Cause

The select_notes_for_amount function greedily selects all notes needed to cover the amount. When many small notes exist, the resulting state transition includes one Orchard spend proof per note, pushing the serialized size past the gRPC/Platform limit.

Questions

1. What is the exact size limit for state transitions?
2. Is there a maximum number of Orchard spends per transition?
3. Should the limit be enforced in the DPP builder (with a typed error) rather than failing at the gRPC transport layer?

Related

• Asset lock state transition rejected as "Tx too large" after Core broadcast — funds stuck #3399 — same "Tx too large" error for asset lock transactions with many UTXOs (different transition type, same root cause: too many inputs)

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

[lklimek]

This CAN be tenderdash-side issue, but we still need a fix in dash-sdk to NOT allow too big txs.

[QuantumExplorer]

Let's have the max inputs be 16. Let's make sure that at least for transactions that have shielded proofs that the transaction limit is big enough.