Skip to main content
MonitorTransaction is a server-streaming RPC — the server pushes status updates until the transaction reaches a terminal state. This guide covers production usage: understanding the full lifecycle, handling every terminal outcome, and reconnecting reliably when the stream drops. For request and response field documentation, see the MonitorTransaction reference.

Stream lifecycle

When you call MonitorTransaction, the server begins watching the transaction’s on-chain status and emits a new response each time it advances. The stream closes automatically when the transaction reaches a terminal state.
TIMEOUT means the monitoring window expired (default: 60 seconds), not that the transaction failed. The transaction may still be processing on-chain.DROPPED means the transaction was not processed by any validator. If the blockhash has not yet expired, you can resubmit the same transaction.

Basic stream consumption

The minimal pattern to read a MonitorTransaction stream and handle terminal states:

Handling terminal states

Each terminal state requires a different response. FINALIZED — The transaction succeeded and is permanent. No further action needed. FAILED — The transaction executed on-chain but failed (for example, insufficient balance or a program error). Check error_message for details. See the Error Reference for error codes. Do not resubmit the same transaction — the failure is deterministic. DROPPED — The transaction was not processed. Check whether the blockhash has expired using CheckIfTransactionIsExpired. If the blockhash is still valid, resubmit with SubmitTransaction. If expired, recompile with CompileTransaction to get a fresh blockhash, then re-sign and resubmit. TIMEOUT — The monitoring window expired (default: 60 seconds). The transaction may still be processing on-chain. Two options:
  1. Call GetTransaction to check current status.
  2. Start a new MonitorTransaction call with the same signature.
The reconnection section below shows how to handle both stream errors and TIMEOUT automatically in production code.

Production pattern: reconnect with backoff

In production, two things can go wrong beyond terminal states: the gRPC stream itself can drop due to a network error, or TIMEOUT can fire before the transaction finalizes. The pattern below handles both — it retries on stream errors with exponential backoff and restarts monitoring on TIMEOUT.

Choosing a commitment level

By default, MonitorTransaction monitors until CONFIRMED. To wait for FINALIZED (a stronger finality guarantee), set commitment_level to COMMITMENT_LEVEL_FINALIZED in the request. For most applications, CONFIRMED is sufficient — finalization is rarely missed after confirmation.

Including execution logs

Set include_logs: true in the request to receive program execution logs in each status update. Useful for debugging failed transactions. Logs are populated in MonitorTransactionResponse.logs on PROCESSED and later statuses.

Next steps