How it works
To use our services well, it helps to understand the path a Solana transaction takes from the moment it is sent to the moment it is final, and where each MEV Alpha Store service connects to that path.
Time on Solana
- Slot. The basic unit of time, targeted at about 400 milliseconds. In each slot one validator, the leader, is allowed to produce a block.
- Leader rotation. Each leader produces blocks for four consecutive slots, roughly 1.6 seconds, before the next leader takes over.
- Epoch. 432,000 slots, roughly two to three days. The leader schedule for every epoch is known in advance and is derived from validator stake.
Because the leader changes every few slots and the schedule is public, the question is never only *what* to send, but *where* and *when*.
The life of a transaction
- Submission. A wallet, dApp or bot signs a transaction and sends it, usually to an RPC node.
- Forwarding. The RPC node forwards the transaction to the TPU (Transaction Processing Unit) of the current leader and, typically, the next leaders. Solana has no public mempool: transactions travel directly to leaders.
- TPU ingress. The leader receives the transaction over QUIC. Connection capacity is allocated according to stake (stake-weighted QoS), so traffic from staked peers is prioritized over unstaked traffic.
- Execution. The leader verifies signatures, executes the transaction in its banking stage and records it into entries.
- Shredding and propagation. The entries are split into shreds and propagated to the rest of the network through Turbine, a tree-shaped fan-out, while the slot is still in progress.
- Replay. Other validators reassemble the shreds into the block and replay (re-execute) it. Only after replay does the data appear in standard RPC responses and WebSocket subscriptions.
- Confirmation. Validators vote on the block. The transaction moves through the commitment levels processed, confirmed and finalized.
Where our services connect
| Step | Service | What you gain |
|---|---|---|
| 3. TPU ingress | Private Orderflow | See transactions as they reach validators in our network, before execution |
| 2–3. Forwarding and ingress | Private TPU Send | Your own transactions reach the leader over staked, prioritized connections instead of public paths |
| 5. Shredding and propagation | Shreds (Early Data) | See what the leader is putting into the block before replay |
| Leader rotation | Leader-aware routing in Full Stack | Each transaction goes to the leader that will actually process it |
Why the head start matters
Most market participants observe the chain through RPC nodes, which means they see a transaction only after step 6. Private Orderflow moves your view to step 3, and Shreds move it to step 5. In a network that produces a block every 400 milliseconds, a lead of tens to hundreds of milliseconds is frequently the difference between capturing an opportunity and missing it.
On the execution side, a transaction that waits in shared queues or arrives at a leader that has already finished its slots is simply late. Private TPU Send and leader-aware routing shorten and stabilize that path.
Commitment levels
| Level | Meaning | Typical use |
|---|---|---|
| processed | The node has processed a block containing the transaction. The block may still be skipped or end up on a minority fork. | Fastest feedback, not safe for accounting |
| confirmed | A supermajority of stake has voted on the block. | Most trading decisions |
| finalized | The block has been rooted and cannot be rolled back. | Settlement and reporting |
Data from Private Orderflow and Shreds arrives before any of these levels. Treat it as an early signal and confirm outcomes through your RPC at the level your strategy requires.
Need help or access? Contact our support on Telegram.
Contact