Fuel network
Fuel network transfers require funded inputs before you authorize a payment
Last updated:
Fuel network transfers need spendable inputs that cover the selected asset amount and the transaction fee. Prepare the recipient address, confirm the asset identifier, and review the assembled request before authorizing submission. After processing, compare the recorded transfer with the payment that you intended. A displayed balance alone does not establish that the request has suitable inputs, and a submission acknowledgement does not establish successful execution.
1. Spendable funds in the selected account
The sending account must hold usable resources in the Fuel environment where the payment will execute. Fuel represents spendable coins as unspent transaction outputs, or UTXOs, each carrying an owner, asset identifier, and amount. Transaction preparation selects these resources rather than spending an abstract portfolio total. Confirm the account and environment before assessing available funds. Wallet compatibility also matters: the connected account must support authorization of the actual transfer request.
2. Destination and transfer type
The destination determines which transfer operation applies, so establish whether the recipient is an account or a deployed contract before preparing the request. A valid-looking identifier does not establish that the selected operation matches its purpose.
Account recipients
An account transfer specifies the recipient address, amount, and asset identifier. Check the complete destination against the receiving account details. The asset identifier determines which asset moves; a display name does not replace it. A transfer between Fuel accounts also stays within the selected Fuel environment. Moving funds between networks requires the applicable bridge operation, with its own prerequisites.
Contract recipients
A contract transfer funds a deployed contract through the operation intended for that destination. The TypeScript SDK distinguishes account transfers through transfer from contract funding through transferToContract. Sending assets to a contract also does not, by itself, establish that an application has credited a deposit or performed another requested action. That outcome depends on the application’s contract behavior.
3. Can the transfer inputs cover both the payment and its fee?
The request needs sufficient inputs for every asset that it spends, including the base asset used for fees. Funding the payment asset alone leaves preparation incomplete when the transaction lacks fee resources.
Payment amount and fee allowance
A base-asset payment draws its transfer amount and fee funding from the same asset. A payment in another native asset needs that asset for the recipient and base-asset resources for the fee. Compare those requirements separately. Increasing the quantity of the payment asset cannot repair a shortage in a different fee asset.
Fee preparation accounts for transaction processing and any execution that the request requires. Input and output processing contribute to the cost, alongside other intrinsic work. Review the estimated charge and the maximum fee allowance as different values. The allowance bounds the permitted fee; it does not state the final charge.
Selected coins and returned change
A Fuel transaction consumes each selected coin input in full. The selected input total can therefore exceed the intended payment. A change output returns the unused balance for its asset to the designated address. Review that address when inspecting a custom request, especially if multiple accounts contribute resources. The size of an input alone does not tell you how much the recipient receives.
The payment output, change output, and fee allocation explain where the selected funds go. Checking their destinations prevents an input total from being mistaken for the payment amount.
4. Conditions for advancing to authorization
Before authorizing a prepared request, check that its destination, funding, and spending conditions match the intended payment. An unresolved item means the request needs correction while it remains unsigned.
- Each contributing account can authorize its required inputs in the intended Fuel environment.
- The recipient identifier belongs to the intended account or contract, and the transfer operation matches that destination.
- The asset identifier and amount match the payment, without relying solely on a token name.
- The assembled request includes sufficient payment resources and base-asset fee funding.
- The fee allowance and change destination are acceptable, including any contribution from another account.
Transaction assembly can select resources, estimate fees, and perform a dry run. These checks help expose missing funding before submission. They do not resolve a mistaken recipient that the sender supplied.
5. Authorization and submission
An unsigned request remains editable, while releasing spending authorization allows the transaction to proceed through the submission flow. Inspect the actual request at that boundary; wallet interfaces can combine signing and broadcasting into one action. The SDK also supports preparing a transfer request separately from submitting it. Reject an unexpected request before authorization. Once a transaction has successfully executed, closing the application does not undo the recorded transfer.
6. Matching the processed record to the payment
The processed transaction record must identify the intended recipient, asset, and amount before the payment can be treated as correctly executed. Retain the transaction ID from submission and use it to locate that record. A submitted status leaves the execution outcome unresolved. For an ordinary account transfer, inspect the recipient coin output alongside the successful status.
Reconcile the payment with the recorded fee and any change returned to the sending account. Compare amounts in consistent units. The sender’s balance movement includes the fee when the sender funds it, so it need not equal the recipient’s increase. A balance screen without the corresponding transaction details provides less information about what happened. The transaction response exposes status, operations, receipts, fee information, and block details for this check.
7. Resolving an insufficient-funds error before retrying
An insufficient-funds error during preparation calls for checking the missing resource, starting with the payment asset and the base asset separately. Confirm that the request refers to the intended account and environment. A fee shortage requires usable fee funding, or a smaller payment when the payment itself spends the base asset. Reducing an unrelated asset amount does not supply the missing fee asset.
After correcting the shortage, rebuild the request using available resources and review its updated fee allowance. If an earlier attempt reached submission, use its transaction ID to check the recorded outcome before creating another payment. A network acknowledgement and a completed transfer are different outcomes. Retry only after establishing what the earlier attempt did, so a preparation error does not turn into a duplicate payment.
Fuel network: reader questions
Can another account pay the fee for my Fuel transfer?
Fuel transaction assembly supports a fee payer that differs from the account supplying the payment asset. The participating accounts must provide the required resources and authorization. Change needs particular attention when both accounts contribute the same asset: Fuel permits only one change output per asset identifier, so the selected change destination receives that asset’s combined remainder.
Does preparing a Fuel transfer create a transaction ID before submission?
A prepared Fuel transaction can have an ID before submission. Preparing that identifier does not broadcast the payment or prove execution. Changes to transaction fields that participate in the ID calculation can produce a different identifier, so retain the ID associated with the final submitted request.
Why can the raw transfer amount look different from the wallet amount?
Raw transaction amounts use integer units, while a wallet can display a decimal amount using the asset’s precision. Compare the asset identifier and conversion settings before treating the difference as an incorrect payment. Display rounding can also hide smaller units that remain present in the recorded integer amount.
Is a separate Fuel transaction required for every recipient?
Fuel supports transfers to multiple account recipients within one transaction through the SDK’s batch transfer method. Each recipient entry specifies its destination, amount, and asset identifier. Review every entry and the combined funding requirement before authorization. Contract recipients use the separate batch operation intended for contracts.
What happens if two prepared Fuel transfers select the same coin?
A spent Fuel coin cannot fund another transfer. Two prepared requests that depend on the same input therefore cannot both spend it successfully. After one request consumes that coin, the other needs available resources instead. Transaction assembly supports resource exclusions, which applications can use when coordinating concurrent requests.