Stream Semantics

Latency ordering

For a transaction that this validator ends up seeing:

/v1/incoming  ≈  /v1/accepted   →   /v1/pending   →   /v1/executed

• /v1/incoming fires the moment a client submits a transaction directly to this validator over the standard Sui gRPC endpoint, before the validator runs any validation or signature check. Frames may include transactions that are later rejected as invalid.
• /v1/accepted fires at network ingress when any peer block arrives at this validator, before block verification. Each block carries many transactions; the same transaction may appear in multiple blocks (peers often re-propose). Frames may include transactions that never commit.
• /v1/pending fires after consensus has ordered the transaction but before execution. One frame per ordered transaction.
• /v1/executed fires after execution, carrying the full transaction data plus effects and events.

/v1/incoming coverage

/v1/incoming only emits transactions that arrive at this validator’s own gRPC submit endpoint. Most Sui clients submit to a single validator, so each individual validator sees only a fraction of network-wide transactions on this stream. The benefit is latency: it’s the earliest possible point of observation — the bytes are emitted before any deserialize/validate work runs.

For complete coverage of all transactions reaching the network, subscribe to /v1/accepted as well. /v1/accepted sees every block proposed by every peer, so it eventually includes every transaction the network agrees on — at the cost of duplication and some phantom transactions.

Reconciliation

Frames on /v1/incoming and /v1/accepted are speculative: a transaction appearing there may be rejected later in the pipeline. If execution certainty matters, cross-reference by transaction digest against /v1/pending or /v1/executed.

What's next?

• Wire Formats & BCS Conventions
• Submission & Versioning