TIN - MEV Services

The Rakurai Transaction Inclusion Network (TIN) is a decentralized aggregator that enables lightning-fast transaction inclusion and MEV sharing for Rakurai validators. It allows multiple transaction-landing services to access Rakurai stake and send transaction and bundle orderflow for inclusion.

For a validator, TIN provides an additional source of revenue on top of block rewards and Jito tips. For a searcher or landing service, it provides a way to reach Rakurai stake through their own block engine and use pre-confirmations (post-pack confirmations) for backrun and resell opportunities.

Why it exists. TIN brings high-quality orderflow from multiple landing services to Rakurai validators, helping them capture more value from each block without requiring any additional components to run.

Audience: TIN partners, block engines, MEV searchers, and traders sending bundles or consuming post-pack confirmations.

Related: Setup guide · Revenue settlement · Tips · Post-pack confirmations

1. TIN building blocks

TIN has three main integration points. How money from these flows is accounted for is in Revenue streams.

#	Building block	What it does	Who uses it	Guide
1	Multi-block-engine orderflow	Validators connect to all registered landing services and receive bundles from each service for potential block inclusion	Setup guide
2	Virtual priority boost	A SOL tip raises scheduling priority for your transaction or bundle, on top of priority fees	Searchers, traders, landing services	Tips
3	Post-pack confirmations (P2C)	The Rakurai validator streams transactions once they reach the point of no return, providing a front-run-proof signal. Searchers and TIN partners can use this signal to submit backrun bundles or monetize the orderflow by selling it to searchers.	Searchers, TIN partners	Post-pack confirmations

1.1. Multi-block-engine orderflow

Every Transaction Landing Service (TLS) runs a block-engine server and registers its discovery endpoint with Rakurai. The GetBlockEngineEndpoints gRPC API returns the global endpoint along with all available regional endpoints. The Rakurai validator automatically selects and connects to the lowest-latency endpoint. The TLS then forwards bundles through its block engine for potential inclusion in blocks.

Sample implementation: tin_sample_servers

1.2. Virtual priority boost

A tip is a normal SOL transfer into one of the eight Rakurai tip accounts, included in your transaction or bundle. The scheduler uses that amount as a priority signal. Tips are extra on top of priority fees — a large tip with low priority fee still gains little from tip-based prioritization. See Tips and the Minimum Tip Requirements.

1.3. Post-pack confirmations (P2C)

Rakurai pre-confirmation (P2C) is a stream of transactions sent by validators when a transaction reaches the point of no return: early enough to act on, late enough that nobody can front-run the original sender. Each transaction is sent only once (duplicates are suppressed).

1.3.1. Resell

Resell — sell post-pack confirmation to searchers and traders.

PSA — Provides access to the post-pack confirmation stream for reselling. Fee: $50 per 1 million transaction updates, dollar equivalent amount in SOL, charged per epoch.
StartExpiringPacketStream — gRPC service for receiving post-pack confirmations and offering them to searchers and traders.

1.3.2. Backrun

Backrun — allows searchers to analyze transaction streams and submit backrun bundles to capture potential profit. TPU streams is also available.

MCA — Pre-conf is free if you share 65% of backrun profit. If you also sell, fund a PSA for those updates — see access and payments.
StartExpiringMevPacketStream — Streams post-pack confirmations after the point of no return for front-run-protected backrunning.
StartExpiringTpuPacketStream — Streams incoming TPU transactions when the validator is not the leader; these transactions are not protected against front-running.

Full details: Post-pack confirmations and Using P2C.

2. Revenue streams

TIN revenue uses three on-chain account types. Click the diagram for a larger view.

Settlement checklist and CLI commands: Revenue settlement. Download CLIs from the rakurai_programs releases.

Stream	Account	What it is	When you pay	Docs
Tips / Virtual Priority	TCA	Prioritize transactions or bundles for inclusion by sending a tip to any Rakurai tip account.	At send time	Tip Accounts · Tips · TCA
Resell pre-conf	PSA	Pay for selling pre-conf. Fee: $50 per 1M transaction updates.	After each epoch	Rakurai-P2C CLI · PSA
Backrun / MEV Share	MCA	Pre-conf free when sharing backrun; optional TPU. Share: 65% of backrun profit.	After each epoch	Rakurai-RevShare CLI · MCA

Full program overview: Reward Distribution.

3. What TIN means for you

3.1. If you run a Rakurai validator

More blockspace monetization — block rewards, tips, post-pack txn fees, and backrun share.
Higher-quality orderflow — multiple services bid for blockspace.
No extra daemons — TIN lives in the Rakurai client and on-chain programs.
Operator control — Admin RPC lists and blocklists connected block engines and post-pack endpoints.

Start at Validators.

3.2. If you are a landing service, searcher, or trader

Reach Rakurai stake through your own block engine.
Pay for priority you need — tips influence scheduling order. A high tip with a low priority fee still gets little help from tip-based prioritization.
Buy a front-run-proof execution signal — Post-pack PSA access is billed each epoch based on usage ($50 per 1M transaction updates, dollar equivalent amount in SOL) and can be closed when you stop using it.
Settle on-chain — amounts owed are recorded on-chain and checkable with the CLIs.

Start at Setup guide, then Quick start.

4. Quick start

Step	Action	Where
1	Understand what you will owe — TCA, PSA, MCA	Revenue settlement
2	Onboard — share your discovery endpoint and a wallet pubkey you control with the Rakurai team	Setup guide
3	Tip using the Minimum Tip Requirements (always on top of priority fees)	Tips
4	Send traffic — bundles through your block engine	Setup guide
5	Add post-pack (optional) — PSA for reselling, MCA for backrun, or both; consume stream; send backrun bundles	Post-pack
6	Settle each epoch — PSA, MCA, and custom-tip TCA if you use one; download CLIs from the latest release	Revenue settlement

5. Guides

Guide	Description
Revenue settlement	TCA / PSA / MCA checklist and CLI
CLI latest release	Prebuilt `rakurai-revshare`, `rakurai-p2c`, and other Rakurai CLIs
Setup guide	Discovery endpoint, gRPC services, onboarding, Admin RPC
Tips	Sending tips, virtual priority, custom tip accounts, TCA distribution
Post-pack confirmations	P2C overview, PSA, MCA, streaming and reply bundles
P2C Subscription CLI	Fund and inspect PSA
Partner Tip and Mev Revenue Settlement CLI	Settle TCA / MCA

6. Do not double-count tips and converted block rewards

Double-counting risk for indexers

External indexers that watch transfers into Rakurai tip accounts and also watch validator block rewards can count the same SOL twice.

What happens on-chain:

A tip (TCA), PSA fee, or MCA share is claimed to the validator identity.
If block_reward_conversion_enabled is set on that TCA / PSA / MCA account (this flag is on by default), the claimed amount is sent again as a high-priority block-reward transaction during a leader turn.

That block-reward transaction is the converted claim, not new revenue. If you already counted the tip (or the PSA/MCA payout), counting the later block reward as extra income is double counting.

How to avoid it

Read block_reward_conversion_enabled on the TCA, PSA, and MCA accounts (see Reward Distribution — block-reward conversion).
If the flag is on, count the money once: either at the tip / claim, or as the converted block reward — not both.

The conversion transaction must land in that leader turn or it is dropped (it is not forwarded to the next leader).

Validators — setup, upgrades, Geyser, attestation
Programs — on-chain programs and CLIs