The same KAS total can have a different transaction workload
A wallet funded by many mining payouts can have a different set of unspent outputs from a wallet funded by one large receipt. Kaspa transaction costs and constraints are described through transaction mass. The amount you want to sell is therefore not, on its own, a complete description of the transaction the wallet must prepare.
The Kaspa wallet SDK documents a generator that can create a chain of transactions when a set of outputs exceeds a single transaction’s permitted mass. This does not mean every wallet or every mining balance needs such a chain. It means you should read the actual wallet plan rather than promise that any displayed balance can always be sent in one simple operation.
A transfer worksheet for a wallet with many receipts
| Observation | Question to resolve | Keep out of the exchange amount |
|---|---|---|
| Total KAS shown | Which outputs the wallet will use for this payment | A presumed one-transaction guarantee |
| Wallet preparation plan | Whether it includes intermediate transactions | Intermediate movements counted as extra purchases |
| Current network-cost estimate | What the complete proposed sending operation costs | An old fixed fee copied from another wallet |
| Payment to the issued KAS recipient | Which output actually funds the exchange | A transaction total that includes change or preparation |
Read the whole plan before approving the first step
- Establish what is preparation and what is payment
- If the wallet presents several linked operations, ask which one pays the exchange recipient and which ones reorganize funds beforehand. Use the wallet’s supported explanation rather than guessing from a list of transaction identifiers. Do not treat an internal movement as proof of exchange funding.
- Check the intended amount after all sending costs
- Review the actual KAS payment amount and the full fee estimate in the current wallet. Avoid a remembered fee per payout or a rule based only on total KAS. If the plan changes, review the final recipient and amount again before approving it.
- Keep the Bitcoin destination ready
- Get the BTC receiving details from the intended wallet or hosted account. The source wallet’s mining history does not determine the Bitcoin recipient. Keep that payout instruction with the exchange reference so source preparation and destination receipt remain separate.
When several transaction IDs appear, identify the funding record
Save the wallet’s summary and the relevant public transaction references. If the exchange does not yet show the expected funding, first identify whether a transaction actually paid the issued KAS address. A completed preparation step can be real without being that payment. Explain this distinction when asking for the existing transfer to be reviewed.
Do not repeat the whole sending sequence because an intermediate transaction finished or because the wallet balance temporarily looks unfamiliar. Check the original plan and payment status with the wallet first. Once the KAS payment is established, trace the BTC payout as its own record; a chain of source-wallet operations is not a chain of Bitcoin receipts.
Questions about mining-wallet funding
- Does a large number of mining payouts always require several transactions?
- Not always. Inspect the actual wallet plan. The SDK supports chained preparation when a transaction would exceed its mass constraint, but this is not a prediction for every wallet.
- Does every transaction in the preparation sequence pay the exchange?
- Do not assume that. Identify the actual payment to the issued recipient and distinguish it from intermediate or internal movements.
- Can I estimate the whole fee from the KAS amount alone?
- Use the wallet’s current complete estimate. Transaction structure and mass matter, so a balance total or an old fixed fee is insufficient.
Kaspa wallet documentation
Reviewed: