Auto-Select Inputs, Change, and Fees: How the Wallet Builds a Complete Transaction for You

At a Glance

When you call WalletClient.createAction(), the wallet can automatically select spendable inputs, generate a change output, and calculate the fee. This is where the high-level SDK provides the most value for beginners: you describe the desired outputs, and the wallet completes the transaction into a valid, processable one.

Why Automatic Handling Is Needed

In BSV's UTXO model, spending isn't about deducting a number from a balance. Instead, you select several old outputs as inputs and create new outputs.

Suppose you want to create a 100 satoshi data output. Your wallet might not have a UTXO of exactly 100 satoshis. Instead, you have:

• UTXO A: 300 satoshis
• UTXO B: 500 satoshis
• UTXO C: 1200 satoshis

The wallet must decide which UTXO(s) to use. After selection, it must pay a fee. If the total input value exceeds outputs plus fee, the excess must not disappear; typically, it goes back to a change output controlled by the wallet.

Simplified formula:

Doing this manually, beginners often forget change, underestimate fees, select the wrong UTXOs, or construct inputs that cannot be validated.

Wallet Auto-Selects Inputs

When you call createAction() and provide only outputs, the wallet selects inputs from its UTXO set. This selection is not random. The wallet typically considers:

• Whether available UTXOs are sufficient.
• Whether UTXOs are locked or in use.
• Transaction size and fees.
• Whether to reserve certain UTXOs.
• The wallet's own privacy and fund management strategies.

Applications see the result, but should not assume these details do not exist. Automatic input selection is a convenience, not magic.

Wallet Automatically Generates Change

If the wallet selects a 1000 satoshi UTXO, but your target output is only 100 satoshis, the remainder must be handled. A real transaction cannot simply write:

Otherwise, the difference becomes the fee. In most cases, the wallet creates a change output:

The change output is still an on-chain output, spendable in the future. It may also reveal fund associations, so production wallets use strategies to minimize privacy issues.

Wallet Automatically Calculates Fees

Fees typically depend on transaction size, network policy, and miner rates. BSV's large block approach aims for low-cost massive transactions, but each transaction still must meet the fee requirements accepted by the processing network.

SDK and wallet help estimate fees, but applications should still know two things. First, fees are not fixed constants: more inputs, more outputs, and more complex scripts increase transaction size. Second, too low a fee may cause the transaction to be rejected or fail. Automatic estimation reduces error probability but does not guarantee success.

Corresponding Process in createAction

Beginner-level calls often provide only outputs:

You do not write inputs, change, or fees in the code, but the wallet handles them behind the scenes. Later, when you move to lower-level transaction construction, you will explicitly handle:

• inputs: which previous UTXO to reference, what unlocking script to provide
• outputs: to whom, locking script, amount
• fee: total inputs minus total outputs

First understand the automatic flow (Phase 7), then manually dissect (Phase 8).

Position in the BSV Tech Stack

In BSV applications, the wallet layer manages funds. It is not a simple signing button but a UTXO manager, authorization gateway, and transaction construction assistant. This aligns with BSV's layered development:

• Application layer: describes business actions
• Wallet layer: manages UTXOs, authorization, signatures, change, fees
• Network layer: accepts, validates, propagates, and mines transactions
• Indexer layer: allows applications to query business data

As you progress, you will understand each layer's boundaries.

Risks of Automatic Handling

Automatic handling is convenient, but production applications cannot be completely unaware.

• If the wallet selects many small UTXOs, transaction size may increase.
• Poor change strategies may expose addresses or fund associations.
• If the application repeatedly initiates similar actions, it may need idempotency and retry logic to avoid creating multiple transactions for the same business action.
• If network services are temporarily unavailable, transactions may be delayed or fail.

Beginners can rely on automatic handling, but they should know that behind it lies a deterministic transaction structure.

Common Misconceptions for Beginners

• Automatic input selection does not guarantee the optimal combination. Different wallets have different strategies.
• Change is not "internal wallet accounting." Change outputs are real on-chain outputs.
• Fees are not costs to arbitrarily save. Without sufficient fees, a transaction may not be processed.
• A successful transaction creation does not mean the business action is complete. You still need to track status.
• Using high-level interfaces does not mean understanding UTXOs is unnecessary. It's just a different learning order.

References

• First Transaction tutorial
• Large Transactions guide
• Transaction Inputs and Outputs
• Fees concept
• Wallet reference