Cardano BadInputsUTxO: Check the Missing or Spent Input

BadInputsUTxO means a chosen transaction input is not available in the UTXO state used for validation. A common cause is an already spent output, but an incorrect reference or an output not yet known to that state can also need investigation. Check earlier payment attempts and the exact input before asking the wallet to build another transaction.

A balance is not the list of inputs you can reuse

Cardano transactions consume particular unspent outputs and create new ones. The Cardano EUTXO explanation describes that one-use relationship. A wallet can still show a positive total while a previously selected input is no longer available. The remaining balance may live in different outputs, including change from an earlier transaction.

Record the input reference, not only the receiving address. The reference identifies a particular output of a prior transaction. A wrong output index can therefore point to something different from the output you meant to use. A familiar address and sufficient total ADA do not repair that reference.

In an ordinary wallet workflow, the application chooses inputs for you. If it built two payments from the same snapshot, they can compete for an output. Different browser tabs or a recently completed transaction can explain stale selection. This is a reason to compare the actual attempts, not immediate evidence that someone stole funds.

Classify why the input is unavailable

The current transaction-failure guide describes spent inputs and contention as a common BadInputsUTxO case. The official node troubleshooting reference also identifies a bad UTXO index. Avoid reducing all unavailable-input errors to one cause before reading the reference.

Find out whether an earlier payment already happened

Keep the original transaction identifiers and inspect the intended recipient movement. If an earlier attempt already paid the destination, a freshly built payment can create another receipt. The rejection of a later conflicting transaction does not reverse the earlier one. A wallet popup for the newest attempt is therefore not the whole payment history.

If a parent or earlier transaction is still unresolved, establish its state before building a replacement from presumed outputs. Cardano's transaction-building guide discusses provider lag and dependent transactions. Do not copy a short example delay as a guaranteed synchronization time. The data source's actual state is what matters.

A missing explorer result is also not an instruction to repeatedly sign. Check the network, original identifier and wallet's sending record. If you cannot establish whether the intended payment occurred, keep it unresolved and ask official support. Avoid turning uncertainty about one attempt into several new payments with different identifiers.

Rebuilding and resending the old body are different actions

A signed transaction refers to the inputs selected when it was built. Re-signing or resubmitting that unchanged body does not make a spent input unspent. Once the earlier result is understood, a new build can select appropriate current outputs. It must still be reviewed for recipient, asset, amount, change and fees before authorization.

For a wallet user, refresh through the application's supported process and stop concurrent drafts competing for the same funds. Do not edit a serialized transaction in a random website or give a helper recovery words to repair the input. If the wallet repeatedly selects the same unavailable output after a consistent refresh, report the software and provider context.

Developers should trace which state supplied the selected reference and how pending dependencies are handled. An address-level balance check alone is insufficient. The useful diagnostic record includes the selected inputs, the earlier transaction that may have consumed or created them, and the node or provider's relevant view. This is a data-consistency investigation, not a reason to disable validation.

Keep phase-one rejection separate from collateral failure

The transaction-failure guide distinguishes phase-one structural checks from phase-two script execution. BadInputsUTxO belongs to the structural rejection described there. It is not the same event as an included failing script consuming collateral. An estimated wallet fee or a balance change caused by another transaction should not be treated as evidence that this rejected body paid an onchain fee.

Inspect actual ledger records if funds appear lower. A different accepted transaction can have spent an old input and produced change. A token-bearing output may also need enough ADA for its own rules. Use the exact error rather than mixing BadInputsUTxO with a minimum-ADA or insufficient-balance message. Each has a different condition to fix.

Use one fictional input to test your explanation

Suppose two fictional drafts both select Output Birch-0. Draft A is accepted and spends it. Draft B later reports BadInputsUTxO. If A already delivered the intended payment, B is not evidence that the payment failed. If B was for a different obligation, rebuild it using the actual remaining outputs only after A's result is clear.

Birch-0 is a placeholder, not a usable transaction reference. In another case, the application may have mistakenly selected Birch-1 when the desired output was at index 0. The same error family then concerns a reference problem. Preserving the precise output reference distinguishes these cases better than saying the wallet has enough ADA.

1. Save the exact error, selected input references and all relevant attempt identifiers.
2. Check the Cardano network and the intended recipient's actual receipt.
3. Determine whether the input was spent, wrongly referenced or not yet known to the validating state.
4. Resolve earlier or dependent transactions and refresh the wallet's supported view.
5. Rebuild only when another payment is genuinely needed, then review the new transaction fully.
6. Report repeated stale selection through official support without disclosing wallet secrets.

Use the Cardanoscan guide for records and minimum ADA in outputs for that separate constraint. Before a no-account swap, follow the order's current deposit instructions and verify any prior payment. A successful rebuild does not prove the old attempt never reached its recipient.