The Pye CLI is a lightweight command-line tool designed for validators in the Pye ecosystem. It calculates and facilitates the distribution of staking rewards - including inflation, MEV, and block rewards - between validators and their stakers, based on the terms specified in each Pye Account.
By running the CLI, validators enable transparent, trustless accounting for the rewards owed to stakers who delegated to them. This tool is a foundational component of the Pye protocol, ensuring system integrity while automating reward attribution and distribution at the validator level.
Why It Matters
Our mission at Pye is to build Solana’s reward curve. We’re transforming Solana’s PoS into an efficient reward market powered by validators. This unlocks better reward opportunities for stakers and creates new market dynamics for fixed-reward products. To maintain trust and accuracy, the protocol needs a reliable way to measure on-chain rewards and allocate them in accordance with each reward’s terms. This is where the Pye CLI comes in: It serves as the accounting engine that bridges actual validator performance with reward-level reward entitlements.
How does it work?
At the end of every epoch, the Pye CLI tracks the staking rewards generated by a validator node and performs the following operations:
Step 1: Gross Reward Tracking
The CLI calculates the total gross rewards a validator earned in the given epoch, including:
- Inflation Rewards
- Block Rewards
- MEV Rewards
These are sourced directly from Solana’s runtime metrics and on-chain accounts.
Step 2: Adjustments based on TVL Contribution
After measuring the total rewards for the epoch, the CLI calculates the portion of those rewards attributable to each active reward based on its share of the validator's total TVL. This is a straightforward proportional calculation:
\[ R_{p} = \frac{D_{p}}{D_{v}} \times R_v\]
Where:
- \( R_p\) is reward attributable to the Pye Account, pro rata
- \( D_p\) is the # of SOL delegated by the Pye Account for that epoch
- \( D_v\) is the total # of SOL stake delegated in that epoch
- \( R_v\) is the total # of SOL rewards generated in that epoch
Step 3: Adjustments based on Reward Terms
The final step in the accounting process is to adjust the reward's maximum potential reward (from Step 2) according to the specific terms defined in the reward at issuance. Each reward specifies how much of each reward type the validator commits to share with the rewardholder. These parameters are:
- MEV Commission: Percentage of MEV rewards shared with the staker.
- Block Commission: Percentage of block rewards shared.
- Inflation Commission: Percentage that the validator keeps from inflation rewards.
\[ R_v = I_v + B_v + M_v \]
Where:
- \( I_v\) is the # of SOL rewards generated from inflation,
- \( B_v\) is the # of SOL rewards generated from block rewards,
- \( M_v\) is the # of SOL rewards generated from MEV,
for that epoch. These terms govern how much of the validator’s total rewards are actually passed through to the staker .
Step 4: Accounting and Payment Distribution
Once calculations are complete, the CLI handles reward payments in a way that is atuomated and independetly verifiable by the validator operator. The CLI performs the following tasks at the epoch boundaryL
- It generates a txn payload for the amount of SOL the Pye Account is owed for the last epoch.
- This payload is stored in the CLI’s database and is viewable as a report on the individual Pye Account page or the validator’s profile in the app.
- The CLI automatically pulls funds from a pre-funded reward account for the payload amount.
Note this is a separate wallet from the vote account – which validators maintain specifically for reward payments.
This final step ensures timely, on-chain delivery of rewards to stakers in a way that is monitorable by both the staker and the validators.
Read our docs to learn more:
