Transaction Lifecycle

A Solana transaction is not just "sent." It is built, signed, submitted, scheduled, executed, and confirmed under a short freshness window. If one stage is unclear, teams often debug the wrong layer: a quote issue becomes an RPC issue, a stale blockhash becomes a wallet issue, or an accepted send response gets mistaken for final confirmation.

Use this page as the lifecycle map. It explains where each stage belongs and points to the deeper Carbium pages that own the implementation details.

Part of the Carbium Solana infrastructure stack.

The path from intent to confirmation

The normal path has seven stages:

App intent: a user, bot, or backend chooses the action.
Build message: the app or API prepares instructions, accounts, fee payer, and blockhash.
Sign: the wallet or backend signer authorizes the exact message.
Submit: RPC relays the signed transaction.
Schedule and execute: the leader validates locks, fees, and instructions.
Confirm: the client checks signature status.
Recover or settle: the app retries, rebuilds, waits, or marks final state.

The important production habit is to log each stage separately. A failure before signing needs a different response than a failure after sendTransaction returns a signature.

Stage map

Stage	What is decided	Common failure	Carbium handoff
Intent	What action the app is trying to perform	User asks for an impossible pair, size, or route	Supported DEXs and Routing Sources
Build	Instructions, accounts, recent blockhash, fee payer, and optional transaction payload	Missing route, missing `txn`, wrong parameter family	Q1 and Swap API Errors Reference
Sign	Wallet or backend signer authorizes the exact message	User delay, rejected signature, wrong signing boundary	Carbium for Wallet Developers
Submit	Signed payload is sent through RPC	HTTP error, JSON-RPC error, preflight failure	Sending Transactions through Carbium RPC and RPC Errors Reference
Confirm	App checks whether the signature processed, confirmed, or finalized	Accepted send response treated as final state	Solana Commitment Levels
Recover	App decides whether to wait, check status, rebuild, or stop	Blind resend, stale blockhash, duplicate intent	Blockhash Expiry Recovery Playbook

What Solana requires from every transaction

Every normal Solana transaction carries:

one or more instructions
account metadata for the accounts those instructions read or write
required signatures
a recent blockhash
a fee payer

Solana executes all instructions in a transaction atomically. If one instruction fails, the state changes from the full transaction are reverted. Fees can still be charged, so production code should treat simulation and preflight failures as real operational signals rather than harmless noise.

The recent blockhash is the freshness boundary. Solana's current transaction docs describe recent blockhash validity as 150 slots. Once that window is gone, resending the same signed payload will not make it fresh. Rebuild the transaction, get a new signature when needed, and check existing signature status before creating duplicate intent.

📘
A successful RPC send response means the node accepted the signed transaction for relay. It does not prove the transaction processed, confirmed, or finalized. Always follow with signature-status checks that match your product's commitment requirement.

Carbium swap flow

For a Carbium-backed swap, the lifecycle usually looks like this:

Backend requests a Q1 quote from https://api.carbium.io/api/v2/quote.
If the response has no txn, fix the quote shape or route issue before signing.
If the response includes txn, the signer approves the transaction.
Backend submits the signed payload through Carbium RPC.
Backend checks signature status at the commitment level the product requires.
The app settles user state, waits, or enters the recovery policy.

This split keeps product responsibilities clean:

Layer	Owns
Carbium Swap API	Quote, route plan, and executable transaction construction when `user_account` is included
Your signer	Authorization of the exact transaction message
Carbium RPC	Submission and confirmation checks for the signed payload
Your app	User state, retry policy, logging, and final UX decision

For the full code path, use Executing Swaps. For a narrower backend relay pattern, use Sending Transactions through Carbium RPC.

Freshness, commitment, and retries

Transaction bugs often come from mixing three separate decisions.

Decision	Bad shortcut	Better policy
Freshness	Reuse an old signed payload after the user paused	Rebuild and re-sign after the blockhash window is no longer safe
Commitment	Treat every product state as `finalized` or every state as `processed`	Pick `processed`, `confirmed`, or `finalized` by user risk and UX need
Retry	Resend because the UI is still spinning	Check signature status first, then decide whether to wait, rebuild, or stop

sendTransaction can run preflight checks before submission unless your client disables them. If preflight fails, preserve the error body and simulation details. If submission succeeds but confirmation is unclear, move to signature-status checks instead of rebuilding immediately.

Failure routing

Use this quick routing table when a transaction path breaks.

Symptom	Likely layer	Start here
`txn` is empty in a Q1 response	Quote-build request shape	Swap API Errors Reference
Wallet rejects the signature	Signing boundary or user approval	Carbium for Wallet Developers
RPC returns HTTP or JSON-RPC error	Submission or preflight	RPC Errors Reference
`BlockhashNotFound` or block-height expiry appears	Freshness and resend policy	Blockhash Expiry Recovery Playbook
Signature is returned but UX never settles	Confirmation policy	Solana Commitment Levels
Route worked in quote but transaction failed later	Signing, freshness, fees, accounts, or on-chain execution	Executing Swaps

Minimal production checklist

Before a transaction flow goes live, make sure your app can answer these questions from logs:

Which app intent created the transaction?
Which quote, route, or instruction set was used?
Which recent blockhash or validity window was attached?
Who signed, and when?
Which RPC endpoint submitted the transaction?
Did sendTransaction return a signature?
Which commitment level does the product require before the UI advances?
If recovery ran, did it check the original signature before rebuilding?

That is the difference between a debuggable Solana pipeline and a pile of unrelated error messages.

🔶
Build the lifecycle one layer at a time: start with Core Concepts, choose confirmation policy with Solana Commitment Levels, and use carbium.io when you are ready to wire the stack into production infrastructure.