Shiroi Tips

1. Overview

Shiroi Tips is a system composed of on-chain programs and off-chain execution infrastructure that enables:

  • priority transaction delivery under extreme network congestion,

  • participation in auctions for competitive write-account opportunities,

  • parallel execution of bundled and non-bundled transactions,

  • provable and auditable accounting of tips,

  • validator-native monetization aligned with long-term stake.

An opportunity represents any contested write-account or state transition, such as:

  • token purchases,

  • arbitrage executions,

  • NFT mints,

  • market interactions,

  • any transaction competing for the same writable state.

Unlike traditional tip mechanisms, Shiroi Tips eliminate shared writable accounts on the hot execution path by using per-user sharded state, allowing the Solana runtime to execute transactions in parallel without write-lock contention.

2. Design Goals

  1. Eliminate write-lock contention on tip-related accounts.

  2. Preserve parallel execution under extreme transaction load.

  3. Enable opportunity-level auctions without global bottlenecks.

  4. Provide verifiable and auditable post-epoch accounting.

  5. Enable validator-controlled economics and staker participation.

  6. Remain fully compatible with Solana’s runtime and scheduler model.

3. Terminology

  • Tip PDA — a per-user PDA holding tips for a given epoch.

  • User Stats PDA — a per-user PDA storing statistics used for reputation.

  • Distribution PDA — an epoch-scoped PDA holding all distributable tips.

  • BBM Block — a block assembled by a BBM (Block Builder Module) node.

  • Opportunity — a contested write-account or execution right.

  • Reputation — a score derived from historical user behavior.

  • Bounty — a bonus paid to the actor who force-closes an expired tip account.

4. System Components

4.1 On-chain Programs

4.1.1 Shiroi Tips Program

The Shiroi Tips Program is responsible for:

  • managing per-user Tip PDAs,

  • managing User Stats PDAs,

  • enforcing tip-account lifecycle rules,

  • updating reputation inputs,

  • recording BBM block provenance on-chain.

The Shiroi Tips Program never aggregates epoch-level funds and never distributes rewards.

4.1.2 Tip Distribution Program

The Tip Distribution Program is responsible for post-epoch reward distribution.

Its responsibilities include:

  • owning the Distribution PDA,

  • storing the Merkle root for a given epoch,

  • holding all distributable funds,

  • validating Merkle proofs,

  • distributing rewards to validators and stakers,

  • enforcing single-claim semantics.

4.2 Off-chain Infrastructure

Block Builder Module (BBM)

  • Executes opportunity-level auctions.

  • Determines transaction inclusion priority.

  • Produces BBM blocks and provides provenance.

TPU / QUIC Ingress

  • Applies rate limits and priority lanes.

  • Uses on-chain reputation state as the source of truth.

5. Account Model

5.1 Tip PDA (Per-User)

Initialized by the user.

  • Seeds: (signer_pubkey, epoch)

  • Owner: Shiroi Tips Program

  • Purpose: temporarily hold user tips for the epoch

Invariant: No two users ever write to the same Tip PDA.

5.2 User Stats PDA

A per-user statistics account.

  • Seeds: (signer_pubkey, "stats")

  • Owner: Shiroi Tips Program

Stores:

  • total tips paid (lifetime),

  • tips paid in recent epochs,

  • number of correctly closed tip accounts,

  • behavioral flags (spam, invalid attempts).

Used as an input to reputation computation.

5.3 Distribution PDA

The only epoch-scoped fund-holding account.

  • Seeds: (epoch)

  • Owner: Tip Distribution Program

Stores:

  • total tips collected for the epoch,

  • Merkle root of the reward distribution,

  • claim metadata (bitmap / flags).

All tips flow directly into this PDA upon user account closure.

6. Tip Payment Flow

  1. The user submits a transaction containing either:

    • a transfer instruction with amount greater than 100,000 lamports, or

    • a direct balance modification from their own program.

  2. Funds are credited to the user’s Tip PDA.

  3. The User Stats PDA is updated.

Key Property: User transactions write only to user-specific accounts, preserving runtime parallelism.

7. Reputation and Priority

Reputation is derived from:

  • volume of tips paid,

  • consistency across epochs,

  • correct lifecycle behavior,

  • absence of invalid or abusive transactions.

Reputation affects:

  • rate limits,

  • access to priority lanes,

  • scheduling preference during congestion.

Reputation is time-weighted and decays, preventing permanent monopolization.

8. Tip Account Lifecycle

8.1 Normal Close (End of Epoch)

After the epoch ends, the user may:

  • close their Tip PDA,

  • reclaim the rent,

  • transfer all accumulated tips directly to the Distribution PDA.

8.2 Early Close

The user may voluntarily close their Tip PDA before epoch end.

8.3 Forced Close (Garbage Collection)

If the user does not close their Tip PDA within a defined grace period (e.g. one epoch):

  • any actor may trigger a forced close,

  • rent is returned to the original user,

  • tips are transferred to the Distribution PDA,

  • a bounty is paid to the actor performing the close.

Purpose: prevent unbounded state growth and incentivize cleanup.

9. BBM Block Provenance

BBM blocks include special transactions invoking the Shiroi Tips Program that:

  • cryptographically prove BBM block assembly,

  • are recorded on-chain,

  • are valid only in canonical BBM-assembled blocks.

Such transactions:

  • cannot succeed in uncle blocks,

  • cannot succeed in non-BBM blocks.

These records are later used during reward computation.

10. Epoch Finalization

After:

  • epoch completion,

  • expiration of the tip-account closure grace period,

the epoch is finalized and reward computation begins.

11. Tip Distribution

11.1 Merkle-Based Accounting

  • A Merkle tree representing reward allocation is computed off-chain.

  • The Merkle root is submitted to the Tip Distribution Program.

  • Anyone can independently verify correctness using on-chain data.

Optional safeguards:

  • multi-signature root publication,

  • challenge windows,

  • governance or rollback mechanisms.

11.2 Distribution Logic

Rewards are distributed to:

  • validators,

  • their stakers,

based on:

  • active stake during the epoch,

  • BBM block participation,

  • penalties for non-BBM slots.

This reduces randomness and aligns incentives with long-term participation.

11.3 Claiming Rewards

After the Merkle root is finalized:

  • validators and stakers may submit Merkle proofs,

  • claims are permissionless,

  • each leaf may be claimed exactly once,

  • funds are transferred from the Distribution PDA.

12. Comparison with Jito Tips

Jito Tips

  • shared writable tip accounts,

  • write-lock contention,

  • serialized execution under load,

  • effectively single-threaded bundle processing.

Shiroi Tips

  • per-user writable tip accounts,

  • no shared hot-path locks,

  • high parallelism,

  • stable latency during congestion,

  • reputation-aware priority lanes.

Key Difference: Shiroi Tips remove write-lock contention as a class of problems.

13. System-Level Benefits

  • higher throughput under congestion,

  • predictable inclusion latency,

  • reduced spam impact on ordinary users,

  • validator-native monetization,

  • provable and auditable accounting.

14. Security Considerations

  • Sybil resistance: cost of entry + time-weighted reputation.

  • Spam resistance: reputation-based rate limits.

  • State bloat prevention: forced close with bounties.

  • Accounting integrity: Merkle proofs and on-chain BBM provenance.

15. Summary

Shiroi Tips provide a scalable, parallel, and verifiable mechanism for transaction prioritization and opportunity-level auctions on Solana.

By replacing shared writable state with per-user sharded accounts and deferring all aggregation and payouts to a single Distribution PDA with Merkle-based claims, Shiroi Tips preserve network liveness, fairness, and performance even under extreme transaction load.

Last updated