Fuel network records let you check whether your first transfer succeeded

The last stop before authorization

Your first transfer should have a defined destination, selected asset, intended amount, and an acceptable fee allowance before authorization. Confirm that the wallet and application refer to the same Fuel environment. Wallet compatibility matters here because a connected account must support the actual transaction request.

Review the recipient and fee information while the request remains unsigned. If either is unclear, reject the request at that point. Signing can authorize submission, and closing a confirmation window afterward does not reliably withdraw that authorization.

After submission, keep the transaction ID so that you can track that specific transfer’s outcome. Creating another transfer introduces a separate request whose outcome also needs reconciliation.

What proves that my first transfer succeeded?

A successful processed status plus a matching recipient output establishes that the intended transfer executed in the recorded Fuel block. Success alone does not tell you whether you entered the destination that you intended.

The recipient output identifies the destination, asset ID, and amount. Match those details against the original request rather than relying only on a token symbol or a wallet notification. For a simple transfer, that output provides more direct evidence of delivery than the sender’s reduced total balance.

Record the containing block as part of the transaction result. Block inclusion gives the transfer a place in the chain’s history. A transfer’s execution result does not, by itself, establish completion of a separate withdrawal or movement through a bridge.

Submitted transactions and unresolved waits

A submitted status means that Fuel has accepted the transaction for processing, while its execution result remains unresolved. The submission time identifies that event; it is not a completion time.

A loading indicator describes the application’s wait. It does not distinguish every possible network state. Likewise, a lost connection can interrupt the return of a result without establishing whether the transaction executed. Querying the existing transaction ID keeps the investigation attached to the original request.

The absence of a record in one view also needs context. Confirm that the lookup uses the intended network and the correct ID. Do not infer a failed transfer solely from an empty search result, then create a replacement before resolving that uncertainty.

View image file

Preconfirmation and block inclusion

A successful preconfirmation reports an expected execution outcome before the transaction appears in a block. Applications that support this mechanism can respond early, and some can reuse resolved outputs in subsequent transactions.

That early response explains why an application may appear ready for another action before block inclusion. Wait for the processed result to verify that the transfer entered a block. An interface may abbreviate those states, so inspect the underlying status when the wording is ambiguous.

Recipient outputs, change, and the displayed balance

Fuel transfers use inputs and outputs, so the amount consumed from an input can exceed the amount sent to the recipient. The transaction can allocate the remainder to change, while also accounting for its fee.

A spent input therefore does not mean that its entire value went to the destination. Read the recipient output separately from the change output. Their addresses and amounts answer different questions: what the recipient received and where the remaining funds went.

Change normally returns through the address selected during transaction assembly. Do not assume that every output belongs to the recipient or that every remainder returns to the same account automatically. This distinction becomes especially relevant when more than one account contributes resources.

Balance displays can also lag behind processing. Different node responses may reflect different chain heights, and an application may retain an earlier balance. Refreshing a read does not create another transfer. Compare the processed output with an updated view of the same account and asset before treating the display mismatch as a payment failure.

Failed execution and removal from the pool

A failed execution and removal from the transaction pool describe different outcomes, with different implications for fees and retries. Fuel exposes a failure reason for each of these states.

A processed failure can have a containing block, receipts, and a charged fee. Script reversion reverses its execution effects, including contract state changes. Fixed coin outputs require separate inspection; a failed script does not justify assuming that every possible asset movement disappeared.

The squeezed-out status means that the transaction left the pool that holds transactions awaiting processing. Read the stated reason before deciding whether a replacement is appropriate. It is a different condition from a transaction that entered a block and failed during execution.

A transaction that reverts during processing can still consume its funded inputs to cover gas. Remaining funds can then exist in new outputs. A retry may therefore require a newly assembled request using available resources, rather than another submission of the original input references.

Fees in the completed record

The completed transaction’s total fee records its actual charge, while a maximum fee policy limits the fee that the request permits. These values serve different purposes.

Fuel’s costs reflect transaction processing and execution. Relevant inputs include transaction size, input and output processing, signature or predicate work, execution gas, and the applicable gas price. A quoted estimate therefore describes a particular request under particular conditions, rather than a fixed price for every first transfer.

View image file

Include the fee when reconciling the account that paid it. An unsuccessful execution can still incur a charge, so comparing only the requested transfer amount with the sender’s balance can produce a misleading discrepancy. Increasing a fee allowance does not correct a wrong recipient or an application error.

A transfer with a delayed balance display

Suppose you have sent your first transfer and want to verify delivery without authorizing a second payment. The destination, selected asset, amount, fee estimate, and observed display states in the two choices below are hypothetical.

A processed recipient output identifies the transfer’s destination and amount. The fee depends on the request and processing conditions. In this example, the recorded transaction has a successful processed status and a matching recipient output, but the wallet’s balance display has not refreshed.

In the first choice, you query the existing record and refresh the recipient balance. The refreshed view then includes the transferred funds. You confirm delivery without submitting another transaction or incurring another network fee.

In the second choice, you prepare a replacement transfer because the old balance remains visible. The replacement has its own fee allowance; signing it would authorize another payment. Before signing, you inspect the original record and find the successful status and matching recipient output. You leave the replacement unsigned, so only the original transfer delivers funds and no second transfer fee arises.

View image file

Receipt terms that explain the result

Receipts describe events during FuelVM execution, while outputs describe the resulting coins and contract state associated with the transaction. Read both in the context of the overall status.

A return receipt records a return from an execution context. Log receipts carry application data, and transfer receipts describe transfers performed during execution. Panic and revert receipts help explain execution failures. A script-result receipt reports the script’s exit result and gas usage.

An individual receipt does not replace the transaction’s overall outcome. A return from one contract call does not prove that everything afterward succeeded. Similarly, application logs require the application’s own meaning to interpret them; their presence alone does not establish that the intended recipient received the expected asset.

Ending the session with an unresolved record

An unresolved transaction can remain under investigation without another authorization. Preserve its ID, network, intended destination, and latest observed status before closing the application. Closing the interface does not cancel a submitted transaction. Leave the outcome unresolved until the record establishes what happened, and do not send a replacement merely because you are ending the session.