Last updated

PSA — P2C Subscription Account

The P2C Subscription Account (PSA) is how you pay when you resell pre-conf (post-pack confirmations).

  • Fee is paid each epoch based on update volume ($50 / 1M txn Updates, dollar equivalent in SOL)
  • Keep the account funded; the epoch fee is deducted when the epoch closes
  • Underfunding gives a grace window rather than an instant cut-off

Backrun-only partners who share through an MCA get pre-conf free — no PSA. If you sell (alone or with backrun), keep a funded PSA.

A PSA is not a tip and not MevShare. Comparison: access and payments.

Audience: Searchers, traders, and TIN partners who resell post-pack confirmations (optionally alongside MCA backrun).

Related: Post-pack overview · MCA · Using P2C · rakurai-p2c CLI


1. Why the PSA exists and how it is priced

A PSA is an on-chain account that tracks the transaction updates received for a validator and records the associated fees, transfers, and claims. PSA access for reselling pre-confirmation data is priced based on the number of transaction updates received. If you share backrun revenue through an MCA, PSA access is provided at no additional cost.

  • One PSA per service, per validator. Ten validators means ten PSAs under the same service name.
  • The fee is based on txn Updates. Baseline: $50 / 1M txn Updates, dollar equivalent amount in SOL. At epoch end the program prices the fee from streamed update volume for that validator.
  • The fee splits two ways: a commission to Rakurai (commission_bps), and the remainder to the validator.

If block_reward_conversion_enabled is on (the default), that validator remainder is later converted into a high-priority block reward. Do not count it twice — see the indexing note.


2. Account status and the grace window

Every PSA has a status that controls whether the stream keeps flowing.

StatusMeaningStream
ActiveFees are currentDelivered
InGraceRecent epochs were underfunded, still inside the grace windowDelivered
SuspendedThe unpaid streak exceeded grace_epochsStopped

The program counts consecutive underfunded epochs in unpaid_streak against grace_epochs (default 2). Any shortfall also accumulates in deficit.

Suspension stops delivery until the deficit is cleared

Once status is Suspended, the validator stops sending post-pack updates. Funding the shortfall restores delivery, but missed updates are not replayed.

A healthy-looking balance can still be short

total owed and the fund-all shortfall cover past epochs only. The in-progress epoch is not priced yet — keep a buffer above the displayed figure.


3. Lifecycle

  1. Onboard. Contact the Rakurai team — see Setup guide — and share your gRPC endpoint. Also Using P2C.
  2. Rakurai opens the account. A PSA is created for your service name against each validator, and your endpoint is registered. Defaults come from the on-chain P2CConfigAccount.
  3. You fund it. Top up with rakurai-p2c fund, fund-all, or a plain solana transfer to the PDA — anyone may fund it.
  4. The epoch closes. Update volume is priced and the fee is deducted from the account balance.
  5. You keep it topped up. Check status and deficit each epoch and fund before the streak hits the grace limit.
  6. You leave. Once every billed epoch is paid, the account can be closed and the leftover balance is returned.

4. Checking your account

rakurai-p2c \
  --url <RPC_URL> \
  --program-id <REWARD_DISTRIBUTION_PROGRAM_ID> \
  get-account \
  --name <SERVICE_NAME> \
  --vote-pubkey <VALIDATOR_VOTE_PUBKEY>

This prints the derived PDA, balance after rent exemption, total owed for past epochs, status, and deficit when above zero. Add --detail for per-epoch rows and commission settings.

Use get-all-accounts --name <SERVICE_NAME> to see every validator you subscribe to in one table.

Full command reference: P2C Subscription CLI (rakurai-p2c). On-chain struct: Reward Distribution — PSA.


  • MCA — backrun path (can be used with PSA)
  • Using P2C — Relayer gRPC stream and reply bundles
  • Tips — landing tips are a separate path from the PSA