Unsigned transaction lifecycle
Review simulation, fees, signers, expiry, and confirmation before treating an operation as settled.
Every direct prepare… method returns a PreparedTransaction. The SDK performs mandatory simulation but never opens a wallet, signs a message, broadcasts, or retries in the background.
Inspect the prepared result
| Field | What your application should do |
|---|---|
transaction, wireBytes, wireBase64 | Pass the supported representation to your wallet adapter; wire encodings include zeroed signature slots |
instructions | Reuse the ordered instructions for explicit composition |
requiredSigners, feePayer | Ensure every required signature is supplied; payer and actor may differ |
programAddress, genesisHash | Confirm deployment identity |
addresses, creations, summary | Show recipients, limits, created accounts, and intended effects |
lifetime | Retain the blockhash and last valid block height for expiry handling |
simulation, computeUnitLimit | Review the final simulation and resource cap |
estimatedNetworkFeeLamports | Show network cost, including priority fees |
estimatedRentLamports | Show account deposits separately from network and token fees |
serializedSize, lookupTables, minContextSlot | Track message size, validated lookup tables, and RPC context |
The priority-fee estimate is included in the network fee; do not add it twice. Rent estimates cover declared SDK creations or growth. Hook-specific deposits and arbitrary composed instructions may add costs.
Sign, submit, confirm
- Present the operation and its bounds to the user.
- Request signatures from every required wallet or signer using its supported v0 interface.
- Submit the signed bytes explicitly through your RPC integration.
- Observe the signature at your chosen commitment and inspect execution errors.
- Reconcile the actual state, token amounts, and fees before showing success.
The wallet and RPC submission code belongs to your application. The SDK does not expose a send or confirm convenience method. For the underlying RPC contract, see sendTransaction and getSignatureStatuses.
Refresh expired or changed plans
Never replace the blockhash in a signed transaction. After expiry, read state again, prepare a new transaction, and collect new signatures. Monotonic RPC context slots are not a frozen multi-account snapshot, and simulation does not reserve state.
Custom instruction composition requires another complete preparation and simulation. prepareInstructions accepts your ordered instructions, address map, creation inventory, and truthful review summary. The caller owns the semantics of those instructions.
Atomicity and size
Prepared v0 transactions must fit 1,232 serialized bytes, including signatures. Oversized plans fail explicitly; the SDK does not split them silently. If you implement a series of transactions, explain which accounts or deposits may remain when a later step fails and rebuild each dependent step after its prerequisites confirm.
See Address Lookup Tables for explicit compression and Solana simulation for RPC behavior.