Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

refactor: prevent creation of rewards with no payout, but with high computational cost #2334

Merged
merged 2 commits into from
Sep 26, 2024
Merged

refactor: prevent creation of rewards with no payout, but with high computational cost #2334

Changes from 1 commit
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
85fa5b6
refactor: preventcreation of rewards with no payout, but with high co…
witgaw Aug 6, 2024
98ad240
refactor: move to appropriate section
witgaw Sep 26, 2024
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
7 changes: 3 additions & 4 deletions protocol/0056-REWA-rewards_overview.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -225,10 +225,9 @@ If a party meets **all** the eligibility requirements, their reward metric $m_ee

In order to allow creation of rewards which can pay-out to parties who are not actively trading, a transfer using this metric should be accepted in the cases where:

- it specifies no metric asset, no markets within the market scope, no staking requirement, and no position requirement - in this case, all parties on the network are given a score of $1$.
- it specifies no metric asset, no markets within the market scope, no position requirement, but does specify a staking requirement - in this case, all parties meeting the staking requirement are given a score of $1$.
- it specifies only one of: metric asset, market scope, staking requirement, position requirement (an asset must be specified also in this case) - all parties meeting the eligibility criteria are given a score of $1$.

If however a position requirement is specified, an asset must be specified also and then parties must meet the position requirement to receive rewards.
Note: at least one requirement must be specified to avoid a trivial attack on the network where an attacker can just keep setting these rewards such that they never get paid but constantly evaluated on the whole network.

### Reward windows and transfer delays

Expand Down Expand Up @@ -1189,7 +1188,7 @@ At the end of epoch 2, 10000 VEGA rewards should be distributed to the `ETHUSDT`

### Valid combinations

- Given a recurring transfer using the eligible entities metric and the below combination of fields, rewards should be uniformly distributed amongst all entities on the network regardless of trading activity.
- Given a recurring transfer using the eligible entities metric and the below combination of fields, rewards should not be distributed since no eligibility criteria are set:
- no dispatch metric specified
witgaw marked this conversation as resolved.
Show resolved Hide resolved
- no markets specified
- no staking requirement specified
Expand Down
Loading