What is the difference between vote and non-vote transactions on Solana?

The distinction is purpose, not transport

A vote transaction records a validator's consensus action through the vote program. A non-vote transaction invokes the rest of Solana's general program environment, including transfers, swaps, liquidations, oracle updates, account administration, and custom application logic.

Once included, both are transactions in the ledger. The leader records them into proof-of-history entries. Those entry bytes are split across data shreds and protected by coding shreds. Turbine does not create one tree for votes and another public tree for market transactions.

Clients can classify recognized simple votes before inclusion for forwarding, scheduling, cost accounting, and quality of service. That fast classification is an implementation and resource-control concern. It does not create a separate block whose ordering can be ignored by a decoder.

For a market-data consumer, the useful split is semantic. Votes update consensus state. Non-votes usually contain the application events a strategy evaluates.

A vote is a Solana transaction

A validator constructs a vote transaction, signs it with the authorized voting credentials and any required payer authority, and sends it toward a leader for inclusion. The instruction targets the vote program and reports a recent fork choice under the validator's tower rules.

The transaction uses the same broad message, signature, account, recent-blockhash, fee, and instruction machinery as other Solana transactions. Runtime rules and client fast paths recognize its specialized shape.

Included vote transactions consume block resources and update vote-account state. Their stake weight matters when the cluster interprets consensus, not because the transaction packet itself is physically larger or placed in a higher Turbine layer.

A raw parser should identify votes from the message and invoked program rather than infer them from packet source, shred position, or arrival time.

Vote state carries lockout history

Solana's tower consensus gives votes lockouts that grow as the validator continues voting on descendants. Vote-account state records enough history and root progress for the protocol to evaluate those commitments.

A vote transaction can contain recent slot and hash context rather than one bare boolean choice. Runtime processing validates that the vote is admissible for the vote account and updates its state.

This state contributes to confirmation and fork choice. A single vote transaction does not finalize a block. Commitment depends on accumulated stake, vote ancestry, lockouts, and the cluster's subsequent progress.

For trading infrastructure, vote transactions are valuable when estimating commitment and fork risk. They are different from an exchange fill or pool update, but filtering them before parsing removes information about how quickly the observed proposal is gaining support.

Simple votes receive special classification

Validator clients can recognize a constrained vote-transaction form cheaply before full execution. The category is commonly called a simple vote.

The classification supports resource policy. Votes are latency-sensitive to consensus and numerous, so clients can separate their scheduling, cost tracking, forwarding, and metrics from general traffic. Exact recognition rules and resource limits change across releases.

Not every transaction that invokes the vote program must qualify for every fast path. Additional instructions, account layouts, signature shapes, or unsupported message forms can move a transaction into general handling even if its purpose involves a vote.

Infrastructure should copy the active client's classifier when exact agreement matters. A home-grown test based only on one program identifier can disagree at edge cases and distort vote-versus-non-vote counts.

Non-vote covers many workloads

Non-vote is a negative category, not one behavior. A one-signature system transfer, a compute-heavy zero-knowledge instruction, a DEX swap, and an oracle update all fall outside the simple-vote class while having very different resource profiles.

The transaction declares accounts and instructions. Account write conflicts constrain parallel scheduling. Compute-budget instructions can request limits and express priority fees. Runtime cost models estimate work before and during admission.

Market traffic is often bursty and concentrated on hot writable accounts. Hundreds of transactions can compete for the same pool, order book, mint, or program-owned state. The leader cannot execute conflicting writes in parallel even when spare cores exist.

An analysis that compares votes with all non-votes should therefore report the heterogeneity inside the latter group. Average compute or latency for non-votes can conceal the programs a strategy actually follows.

Leaders have finite block resources

A slot cannot accept unlimited compute, account data, signatures, write locks, and packet bytes. The leader applies protocol limits, cost-model estimates, scheduling policy, and current bank state.

Vote traffic competes for some physical resources with general transactions, but client cost tracking can place vote work under specialized limits or reserved policy. The exact numeric budgets are version-sensitive and should be read from the active runtime.

Special treatment protects consensus progress during application demand. It does not mean votes are free. They consume network bandwidth, signature verification, banking work, ledger bytes, and replay work.

When a slot is saturated, non-vote inclusion depends on priority, account conflicts, arrival time, validity, and resource headroom. Observing a high vote count alone does not establish why one application transaction was excluded.

Votes follow an earlier block

A validator votes after receiving and replaying a proposed block under its fork and tower rules. That vote must then travel toward a current or upcoming leader and be included in a later block.

The vote transaction seen in slot N usually expresses a decision about an earlier slot or fork ancestor, not about unseen later transactions in slot N. Its inclusion time is downstream from the block data that caused the vote.

This ordering creates a commitment pipeline. Shreds expose the proposal. Replay produces a local bank. Validators vote. Later shreds expose those included votes. Stake accumulation raises confidence.

A feed consumer can model that progression, but network observation is incomplete. Missing a vote transaction does not prove the validator did not vote, and seeing one does not establish the entire cluster's state.

Gossip votes and ledger votes differ

Solana gossip can carry vote-related CRDS values to help disseminate recent voting information. Vote transactions are also forwarded toward leaders for ledger inclusion.

These are related representations with different observation points. Gossip arrival can precede or follow the included transaction depending on paths and timing. The canonical ledger record is the transaction recorded in an entry and propagated as shreds.

An application must label its source. A gossip vote timestamp measures control-plane propagation. A vote transaction timestamp in raw shreds measures block inclusion visibility. An RPC vote-account read measures executed state after replay.

Combining them without source labels produces impossible-seeming sequences and double counts one validator decision. Join on validator and vote context where feasible, but preserve each representation's semantics.

Both types share entry order

The proof-of-history entry stream interleaves vote and non-vote transactions according to the leader's recorded batches. A vote entry can appear between application entries, and one entry batch can contain transactions with different semantic purposes subject to scheduler behavior.

A decoder reconstructs the entire ordered byte stream before applying a filter. Removing vote bytes at the packet layer would corrupt offsets and entry parsing because shreds do not align one-to-one with transactions.

After parsing complete transactions, a consumer can route vote events to a commitment pipeline and application events to strategy handlers. That is a semantic fanout inside the customer's system.

The original slot, entry order, and transaction index should remain attached. Filtering that loses order makes it harder to reproduce bank behavior or explain why two account updates have the observed sequence.

Both types share Turbine uncertainty

An included vote and an included swap can occupy the same data shred. They inherit the same leader signature, packet route, loss event, erasure recovery, and fork uncertainty.

Turbine position does not become earlier because the bytes represent a vote. Client forwarding paths before inclusion can prioritize vote delivery toward leaders, but after recording the block propagation unit is the shred.

If the shred is lost, coding recovery reconstructs all its bytes together. If the block loses fork choice, both transaction types belong to the abandoned proposal. If the receiver is in a later layer, both become visible later.

This shared transport makes a raw feed useful for commitment analytics and market data at once. One decoder can split the semantic streams after reassembly.

Vote volume shapes packet economics

Vote transactions can form a large fraction of transaction count because active validators vote repeatedly as the chain advances. Count is not the same as application payload value or compute cost.

A raw feed carries vote bytes whether the customer trades on them or not. Network capacity must be sized for the complete ledger stream plus coding redundancy, not for a filtered estimate of DEX transactions.

shredstream.sh publishes an observed average of 54.3 Mbps, 5,585 packets per second, and 1,216 mean packet bytes for its feed measurement window. Those are wire observations for the raw stream. They already reflect the traffic mixture present during measurement.

Filtering votes after ingress reduces downstream decode or storage work only after enough packet processing has occurred to identify transaction boundaries. It does not reduce the UDP receive requirement.

Market systems can filter late

The safe low-latency pattern performs structural work first and semantic work second. Validate packet length and variant, deduplicate, recover missing data, reconstruct entries, parse transaction messages, then classify vote versus non-vote.

Some optimizations can overlap. A parser can emit complete transactions from early entry prefixes while later fec sets are still arriving. It can fast-path known vote shapes into a lighter analytics queue. It should not discard unknown layouts as votes.

Keep counters for all transactions, classified simple votes, broader vote-program invocations, and non-votes. Classification drift after a client upgrade should become visible rather than silently changing application throughput.

If commitment analysis is unnecessary, parsed votes can be dropped after metrics. Retaining slot-level vote stake summaries is often cheap and useful for fork-risk diagnostics.

Commitment is stake-weighted, not count-weighted

One hundred votes from small validators do not necessarily outweigh ten votes from large validators. Consensus interpretation uses effective stake associated with voting identities.

A feed consumer estimating commitment needs a current stake map, vote ancestry, duplicate handling, and lockout context. Counting vote transactions in shreds is only a first approximation.

Votes can be delayed, land on different forks, or appear in a block that is itself later abandoned. The observer may also miss shreds. A complete commitment service is substantially more than a program-id filter.

For HFT risk controls, a coarse stake-seen metric can still help if its limitations are explicit. It should be reconciled against trusted commitment data and never represented as protocol finality without implementing the relevant rules.

Arrival time answers different questions

Early arrival of a non-vote transaction answers when a proposed application action became observable. Early arrival of a vote transaction answers when evidence of one validator's earlier consensus decision became visible in the current proposal.

Those signals have different opportunity half-lives. A swap can change a pool state relevant to the next transaction. A vote can change confidence in a fork over a longer sequence of slots.

Measurement should keep separate decode-ready histograms. Vote transactions tend to have recognizable shapes and may parse quickly. Application transactions can require address lookup tables, program-specific decoding, and state joins.

Comparing one combined average can make a decoder appear fast because numerous lightweight votes dominate the sample. Report by class, program, message form, and required enrichment.

The reconciliation path differs

For non-votes, reconciliation commonly checks execution status, logs, account changes, and canonical fork inclusion. A transaction present in a shred can fail or disappear with its fork.

For votes, reconciliation checks vote-account state, observed fork ancestry, stake, and cluster commitment. Duplicate or stale vote observations require consensus-aware interpretation.

Both paths need later executed data. Raw shreds provide proposed order before replay results. A decoder that does not execute the bank cannot know every transaction outcome from bytes alone.

Design optimistic state with typed uncertainty. Application updates, vote evidence, and confirmed results should not share one undifferentiated flag. The rollback and expiry rules are different.

The practical conclusion

Vote and non-vote is a useful semantic division after transaction parsing. It is not a reason to split raw packet intake or assume two propagation classes inside a block.

Votes explain how consensus support accumulates. Non-votes contain most application behavior. Both consume leader resources, enter proof-of-history order, cross Turbine as shred bytes, and remain uncertain until execution and fork choice progress.

A low-latency system should decode the full entry stream, classify with versioned rules, and send each event to the appropriate state machine. It should measure application latency without letting abundant vote traffic distort the result.

The feed delivers bytes early. Semantic filtering and correctness remain receiver work.