> For the complete documentation index, see [llms.txt](https://docs.triton.one/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.triton.one/solana/real-time-streaming/preconfirmations-grpc/stream-and-message-format.md). # Stream and message format Preconfirmations gRPC stream events (SlotStart, SlotEnd, Clip), Harmonic slot framing, raw transaction bytes, and every Harmonic and BAM transaction field. `subscribe_harmonic` and `subscribe_bam` return a stream of `Event`s. | event | meaning | | -------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------- | | `SlotStart { slot }` | a leader began streaming preconfs for this slot (Harmonic) | | `Transaction(matched)` | a matching transaction; `matched.filters` names the filters, `matched.transaction` is the feed's message with the raw bytes | | `SlotEnd { slot }` | no further transactions for this slot will arrive, unless the leader restarts it (Harmonic) | | `Clip { transactions }` | matching transactions were withheld, see [Coverage](/solana/real-time-streaming/preconfirmations-grpc/coverage-billing-and-limits.md#coverage) | | `Reconnected { attempts }` | the stream dropped and was resubscribed; the data produced in between is gone | A `Clip` is a count of the matching transactions withheld on that stream since the previous notice. It names no filter, signature, account or slot. Withheld transactions are not replayed; recover them from the landed block. The server pings every 10 seconds to keep quiet streams open, and the client consumes the pings. A stream with no slot in its region for a while simply yields no events. If you use the proto directly instead of the Rust client, the messages are described in [Other languages](/solana/real-time-streaming/preconfirmations-grpc/other-languages.md#updates). ## Slot framing On Harmonic every transaction sits between its slot's `SlotStart` and `SlotEnd`. After `SlotEnd` for a slot you hold everything your filters matched for it, minus what a `Clip` reports. A stream that subscribes while a slot is open joins at the next `SlotStart`, so the first slot you see is always complete. Slot boundaries arrive whether or not your filters matched anything in that slot. Every pending `Clip` arrives before the `SlotEnd` of the slot it hit, so a slot with no `Clip` between its `SlotStart` and `SlotEnd` is complete for your filters. There is no signal before `SlotEnd` that a slot is complete so far. Rarely, on about 0.25% of slots, a leader restarts a slot: a second `SlotStart` for a slot that already ended, followed by its definitive transactions and a new `SlotEnd`. Rebuild your view of that slot from the new frame; the last `SlotEnd` wins. BAM has no framing and no completion signal. Each transaction names its slot. ## Transaction bytes `matched.transaction.transaction` holds the raw transaction bytes. The client parses what filtering needs without you writing a decoder: ```rust let signature = parse::parse_signature(&bytes)?; let (signature, account_keys) = parse::parse_static_parts(&bytes)?; ``` Legacy, v0 and v1 message formats are supported. `parse::parse` returns the whole decoded `VersionedTransaction`. ## Transaction fields Harmonic (`HarmonicTransaction`): | field | meaning | | ------------- | ---------------------------------------------------------------------------------------------------------------------- | | `transaction` | raw transaction bytes | | `slot` | slot the transaction was preconfirmed in | | `result` | the builder's outcome: success, execution failure or fees only; unset if Harmonic reports one the schema does not know | | `region` | Harmonic region it was received from | | `seq` | preconf delivery batch within the slot, numbered from 0 and delivered in order; not an entry | BAM (`BamTransaction`): | field | meaning | | -------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `transaction` | raw transaction bytes | | `slot` | slot the transaction was preconfirmed in | | `node` | BAM node it was received from | | `sequence` | scheduler order over the life of that node process, with gaps for transactions your filters did not match or a `Clip` withheld; transactions sharing a sequence were bundled together | | `bundle_position` | execution order within that bundle | | `is_revert_on_error` | the bundle reverts on error (bundle intent, not an outcome) | | `result` | the outcome the leader reported to the node: success or execution failure; unset when it was not reported | Read the outcome with `execution_result()`, which returns `None` when it is unset or unknown. ```rust use triton_preconfs_client::proto::preconfs::ExecutionResult; match matched.transaction.execution_result() { Some(ExecutionResult::Success) => println!("succeeded"), Some(other) => println!("failed: {other:?}"), None => println!("outcome not reported"), } ``` {% hint style="warning" %} The generated `result()` returns `Success` for an unset value, so do not use it to decide whether a transaction succeeded. {% endhint %} The BAM schema is still changing upstream; expect fields to be added or trimmed. ## Slow consumers A stream that cannot keep up ends with an explicit status: `RESOURCE_EXHAUSTED` when your client does not read fast enough and the outbound queue fills, `DATA_LOSS` when the stream falls too far behind the feed and the server drops its position. Both statuses are retried by the client's reconnect, which is on by default; the gap is gone. `RESOURCE_EXHAUSTED` also ends a stream that stays over its coverage share, see [Errors and reconnection](/solana/real-time-streaming/preconfirmations-grpc/errors-and-reconnection.md#status-codes). *** :life-ring: Contact support by clicking the chat icon in your [customer dashboard](https://customers.triton.one)\ :briefcase: Sales questions? [Contact us](https://triton.one/contact)\ :sparkles: AI agent? Read [llms.txt](https://docs.triton.one/llms.txt)\ :rss: Follow updates: [Blog](https://blog.triton.one) · [X](https://x.com/triton_one) · [YouTube](https://www.youtube.com/@triton_one_ltd) · [Telegram](https://t.me/tritonone) · [GitHub](https://github.com/rpcpool)