Skip to content

Learn

Why rejected is normal

Frame admits transactions optimistically in 300 ms and executes them strictly at settlement. When execution says no, the chain does not pretend the transaction never happened: it finalises a rejected receipt that anyone can audit. That honesty is a feature, not a failure.

fee only the sole debit a rejection ever makes
0 retries rejected is terminal, just like finalised
4 reasons each one named on the public receipt

Every transaction ends exactly once

optimistic Admitted (not final) sealed into a sub block in ~300 ms
Strict execution checks
nonce is next in sequencefee meets the slot schedulebalance covers amount plus fee
Finalised all pass, value moves
Rejected any fail, fee only
Admission is optimistic and instant. Execution is strict and final. Every transaction leaves execution exactly once, through one of these two doors, and the receipt records which one.

What a rejection actually does

  • The fee is consumed

    Committees, lanes, and validators did real work carrying the transaction. Charging for that work is what makes spamming the network with doomed transactions pointless.

  • No value moves

    The transfer amount never leaves the sender. The token movements table on a rejected tx shows exactly one debit: the fee, split among the fee pools.

  • The outcome is terminal

    Rejected is a final state like finalised. The network will never retry it; sending again with a fresh nonce is a new transaction.

  • It is recorded on chain

    The execution receipt carries the exact reason. Admission decisions stay public and auditable instead of vanishing into a mempool.

The four recorded reasons

Every rejected receipt names its cause. The tx page shows it as a chip next to the status; these are the values it can carry today.

Stale nonce stale_nonce

Another transaction with the same sender nonce was executed first. Classic cause: double clicking send, or two wallets sharing one key.

What to do: Nothing to recover; resend with the next nonce. Wallets that auto query the nonce do this for you.

Underpaid fee underpaid

The offered fee was below the fee schedule for the slot the transaction settled in.

What to do: Resend and let the wallet estimate the fee; the schedule is deterministic per slot, so estimates are reliable.

Insufficient balance insufficient_balance

At execution time the sender could not cover amount plus fee. Admission is optimistic, so a competing transfer may have spent the balance first.

What to do: Check the account page for what actually executed, then resend a smaller amount.

Fee overflow fee_overflow

Amount plus fee overflowed the balance arithmetic. Practically only reachable with adversarial values.

What to do: Use sane amounts; a normal wallet never produces this.

On any rejected transaction page you will see the red status badge, the recorded reason, and a token movements table where only the fee moves. If the numbers net to zero and no recipient credit appears, you are reading a rejection.