Asset lock state transition rejected as "Tx too large" after Core broadcast — funds stuck

[lklimek]

Summary

When funding a Platform address with a large number of Core UTXOs (e.g., 400 tDASH from mining rewards), the asset lock Core transaction is broadcast and accepted by Core, but the subsequent state transition is rejected by Platform with "Tx too large". This leaves funds in limbo — deducted from the Core wallet but never credited to the Platform address.

Reproduction

1. Start a fresh local network (dashmate)
2. Mine repeatedly to accumulate ~500 tDASH across many small coinbase UTXOs
3. In Dash Evo Tool, send 400 tDASH to a Platform address ("Fund Platform Address")
4. The asset lock transaction is broadcast to Core successfully
5. Platform rejects the state transition with:

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

Expected behavior

Either:

• Option A: The transaction should succeed end-to-end (Core + Platform)
• Option B: The transaction should be rejected before Core broadcast, with a clear error message about the size limit
• Option C: If Core broadcast succeeds but Platform rejects, the asset lock should remain recoverable and clearly visible to the user

Actual behavior

• Core transaction succeeds (balance decreases)
• Platform rejects with "Tx too large"
• Asset lock is stored in DET's local database but marked as unused
• No asset locks are visible in the UI
• Funds are stuck — not in Core wallet, not credited to Platform
• Error message is generic ("The platform rejected this request")

Root cause analysis

Transaction size: Mining creates many small UTXOs. Spending 500 of them produces an asset lock transaction of ~74 KB (10 + 500×148 + 2×34 + 60). Core accepts transactions up to ~400 KB, but Platform/Drive appears to have a stricter size limit for state transitions containing asset lock proofs.

Atomicity gap: The flow is two-phase — Core transaction is broadcast first, then the state transition is submitted to Platform. There is no rollback mechanism if Phase 2 fails. This means any Platform-side rejection after Core broadcast results in stuck funds.

Questions

1. What is the maximum state transition size that Platform/Drive accepts? Is it documented?
2. Should Platform validate the asset lock transaction size before the state transition is built, providing a clear pre-flight error?
3. Is there a recommended approach for clients to consolidate UTXOs before creating large asset locks?
4. Should the SDK provide a size check or UTXO consolidation helper to prevent this class of errors?

DET-side mitigations (tracked separately)

• Pre-broadcast transaction size validation with clear error message
• Specific TaskError variant for "Tx too large" with actionable guidance ("consolidate UTXOs first")
• Better asset lock recovery UX for Platform-rejected locks

Environment

• Dash Evo Tool v1.0.0-dev (branch feat/unified-address-input)
• Platform SDK from feat/mempool-support branch
• Local network via dashmate

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