-
Notifications
You must be signed in to change notification settings - Fork 1
Reward Algorithm
The math behind how votes become token payouts.
The Theory guides on Proof-of-Brain and Reward Curves explain why the reward system works the way it does. This guide specifies how — the actual mathematical process that converts vote weight into PXA payouts for creators and curators.
The reward pool (also called the reward fund) is a protocol-managed accumulator that receives 70% of all newly minted PXA tokens. It fills continuously — every block adds a small amount — and drains as posts reach their 7-day payout.
| Parameter | Value |
|---|---|
| Inflation share | 70% of new tokens |
| Fill rate | Proportional to block production (every 3 seconds) |
| Drain trigger | Post payout at the end of the 7-day window |
The pool is a global resource. All active posts compete for shares of the same pool.
Every vote on a post contributes rshares (reward shares) — a raw measure of vote weight.
rshares = voter_PXP × vote_weight_percentage × voting_power_remaining
| Variable | Range | Meaning |
|---|---|---|
voter_PXP |
Account's total Pixa Power | The voter's stake |
vote_weight_percentage |
1%–100% | Partial vote slider |
voting_power_remaining |
0%–100% | Current meter level (depletes with use, regenerates at 20%/day) |
Upvotes add positive rshares. Downvotes add negative rshares. The post's net rshares is the sum of all positive and negative contributions.
The net rshares are passed through a non-linear reward curve function to produce a claims value.
claims = f(net_rshares)
The function f is superlinear — meaning that doubling net_rshares more than doubles the claims value. The exact curve is a convergent approximation to:
claims = net_rshares² / (net_rshares + constant)
Where constant is a protocol parameter (sometimes called content_constant) that controls how steep the curve is. A higher constant produces a gentler curve; a lower constant makes it more aggressive.
| Net rshares level | Reward behavior |
|---|---|
| Very low (few small votes) | Near-zero claims — negligible payout |
| Moderate (several medium votes) | Growing claims — noticeable payout |
| High (many votes or large stakeholders) | Accelerating claims — disproportionately large payout |
The curve ensures that broadly supported content earns significantly more per rshare than narrowly supported content.
The post's claims value is divided by the total claims of all posts paying out in the same period, then multiplied by the available reward pool.
post_payout = (post_claims / total_claims) × reward_pool_balance
This is a proportional system. Each post receives a share of the pool relative to its claims value. The pool is finite — more total claims across all posts means each individual post receives less.
| Recipient | Share |
|---|---|
| Author (creator) | ~65–75% depending on configuration |
| Curators (all voters) | ~25–35% |
The exact ratio is a protocol parameter. The approximate ⅔ / ⅓ split cited in the Method guides reflects the current setting.
The author's share can be paid as:
- 100% PXA (liquid)
- 50% PXA + 50% PXP (default)
- 100% PXP
The author selects their preference via the comment_options operation at post time. If set to the default, half the author reward is automatically powered up.
A portion of the author reward may be paid in PXS, determined by the protocol's current price feed and the post's percent_pxs setting.
The curator share of a post's payout is divided among all voters based on two factors: stake and timing.
Each voter's share is proportional to their curation weight, calculated as:
curation_weight = rshares_contributed × time_discount_factor
The time_discount_factor decreases as more rshares accumulate on the post before the voter's vote. Specifically, each voter's weight is proportional to:
sqrt(total_rshares_after_vote) - sqrt(total_rshares_before_vote)
This square-root formula means:
| Scenario | Curation weight |
|---|---|
| First voter on a post (0 rshares before) | Maximum — the full square root of their contribution |
| Early voter (small cumulative rshares before) | High — large marginal contribution to the square root |
| Late voter (large cumulative rshares before) | Low — diminishing marginal contribution |
Each voter receives a portion of the total curator payout proportional to their individual curation weight relative to the sum of all curation weights.
voter_reward = (voter_curation_weight / total_curation_weight) × curator_pool
Each account has a voting power value that starts at 100% (represented internally as 10,000 basis points).
Each full-strength vote reduces voting power by approximately 2% (200 basis points). Partial votes (using a lower vote weight percentage) consume proportionally less.
power_consumed = 200 × (vote_weight_percentage / 100)
A 50% weight vote consumes 100 basis points (1%).
Voting power regenerates linearly at 20% per day (2,000 basis points per day). Full recovery from 0% takes exactly 5 days.
regenerated_per_second = 10000 / (5 × 24 × 3600) ≈ 0.0231 basis points/second
The rshares a vote contributes are scaled by the voter's current voting power:
effective_rshares = voter_PXP × (vote_weight / 10000) × (current_voting_power / 10000)
Downvotes contribute negative rshares to a post's total. If a post's net rshares drop below zero, its payout becomes zero — the protocol does not charge the author.
| Situation | Effect |
|---|---|
| Upvotes only | Full payout based on positive rshares |
| Mixed up/downvotes | Payout based on net rshares (reduced) |
| Net negative rshares | Zero payout |
Downvotes consume the voter's voting power at the same rate as upvotes but generate no curation rewards for the downvoter.
To prevent the reward pool from growing without bound during low-activity periods, the protocol applies a decay to the pool balance. The pool tends toward equilibrium: tokens flow in through inflation and flow out through payouts, with decay ensuring the pool does not accumulate excessively.
The comment_options operation can specify beneficiaries — accounts that receive a fixed percentage of the author's reward. Beneficiaries are deducted from the author's share before the author receives anything.
beneficiary_payout = author_share × beneficiary_percentage
actual_author_payout = author_share - sum(all_beneficiary_payouts)
Beneficiaries do not affect the curator share.
| Step | Calculation |
|---|---|
| 1. Accumulate rshares | Each vote adds PXP × weight% × voting_power%
|
| 2. Apply reward curve |
claims = rshares² / (rshares + constant) (superlinear) |
| 3. Pool share | payout = (post_claims / total_claims) × pool_balance |
| 4. Author/curator split | ~⅔ author / ~⅓ curators (protocol parameter) |
| 5. Curator distribution | Weighted by sqrt(rshares_after) - sqrt(rshares_before)
|
| 6. Beneficiary deduction | Fixed % deducted from author share |
The reward algorithm is the economic engine of Pixa. Non-linear curves amplify community consensus. Square-root curation weighting rewards discovery. The finite, shared pool ensures competition for quality. Every variable is deterministic, on-chain, and auditable — no black box, no hidden logic, no discretion.