Reward mechanics
Revenue Split
Each proposal independently defines its revenue distribution parameters at the time of deployment.
The primary configuration variable is:
delegateShareBps
This value is expressed in basis points.
Basis points provide a precise and integer based method of representing percentages without relying on floating point numbers.
The system defines:
10000 BPS equals 100 percent
This standard ensures full precision in reward calculations.
For example:
2000 BPS equals 20 percent
3000 BPS equals 30 percent
8000 BPS equals 80 percent
When a proposal receives ETH from the Tax Distributor, the revenue is divided according to this ratio.
The delegate receives the portion defined by delegateShareBps.
The remaining portion is allocated to the voters who have staked tokens in that proposal.
This structure ensures that both delegates and voters are economically aligned while maintaining clear separation between their reward streams.
Voter Rewards
Whenever a proposal receives ETH, the reward accounting system updates immediately.
The process follows these steps:
The delegate share is calculated and separated
The voter share is identified as the remaining portion
The cumulative reward per staked token is updated
The system uses proportional reward accounting.
This means that each staked token earns an equal share of the voter reward pool relative to the total amount staked in the proposal.
If more tokens are staked, each token earns proportionally less per distribution event. If fewer tokens are staked, each token earns proportionally more.
This dynamic ensures that rewards are always aligned with capital weight.
Users do not need to interact with the contract immediately after distribution. Rewards accumulate over time and remain claimable at any point.
The system does not impose time restrictions on reward collection.
Claiming
Users claim their accumulated rewards by calling the claim function on the Proposal contract.
The claim calculation is based on cumulative accounting.
The claimed amount is computed as:
User stake multiplied by the accumulated reward per token minus previously recorded reward debt
This mechanism guarantees:
Accurate proportional distribution
No double counting
No need to iterate over past distributions
Gas efficient reward calculation
All rewards are paid in ETH.
The claim function can be executed at any time by the user, independent of distribution timing.
This pull based design ensures that users remain in full control of their rewards and prevents unnecessary automatic transfers.
Delegate Claim
The delegate’s revenue is handled separately from voter rewards.
When a proposal receives ETH, the delegate share is isolated immediately during distribution.
Delegate rewards are not mixed with the voter reward pool.
The delegate can claim their accumulated share independently using the dedicated delegate claim function.
This separation guarantees that:
Voter rewards are protected from delegate withdrawals
Delegate compensation is transparent
Accounting for both parties remains independent
The result is a clean dual stream reward system where capital providers and proposal creators receive clearly defined and isolated revenue flows.
Last updated