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

Add feature test for make relative return reward include losses #11191

Merged
merged 6 commits into from
Apr 25, 2024
Merged

Add feature test for make relative return reward include losses #11191

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
6 commits
Select commit Hold shift + click to select a range
ad4b923
feat: add FT and AC for relative return
Jiajia-Cui Apr 24, 2024
e7b8b4e
feat: add FT for 116
Jiajia-Cui Apr 24, 2024
fc47a0c
chore: add mark price
Jiajia-Cui Apr 24, 2024
5e66ced
feat: add FT for 117
Jiajia-Cui Apr 25, 2024
901d309
chore: typo
Jiajia-Cui Apr 25, 2024
ea5b009
chore: update market ID in 117
Jiajia-Cui Apr 25, 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
141 changes: 141 additions & 0 deletions core/integration/features/rewards/0056-REWA-111.feature
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,141 @@
Feature: Relative return rewards

Background:
Given the following network parameters are set:
| name | value |
| reward.asset | VEGA |
| validators.epoch.length | 10s |
| validators.delegation.minAmount | 10 |
| reward.staking.delegation.delegatorShare | 0.883 |
| reward.staking.delegation.minimumValidatorStake | 100 |
| reward.staking.delegation.maxPayoutPerParticipant | 100000 |
| reward.staking.delegation.competitionLevel | 1.1 |
| reward.staking.delegation.minValidators | 5 |
| reward.staking.delegation.optimalStakeMultiplier | 5.0 |
| network.markPriceUpdateMaximumFrequency | 0s |
| limits.markets.maxPeggedOrders | 2 |

Given the fees configuration named "fees-config-1":
| maker fee | infrastructure fee |
| 0.005 | 0.002 |
And the price monitoring named "price-monitoring":
| horizon | probability | auction extension |
| 3600 | 0.99 | 3 |

And the simple risk model named "simple-risk-model-1":
| long | short | max move up | min move down | probability of trading |
| 0.2 | 0.1 | 100 | -100 | 0.1 |


And the markets:
| id | quote name | asset | risk model | margin calculator | auction duration | fees | price monitoring | data source config | linear slippage factor | quadratic slippage factor | sla params |
| ETH/DEC21 | ETH | ETH | simple-risk-model-1 | default-margin-calculator | 2 | fees-config-1 | price-monitoring | default-eth-for-future | 0.25 | 0 | default-futures |
| ETH/DEC22 | ETH | ETH | simple-risk-model-1 | default-margin-calculator | 2 | fees-config-1 | price-monitoring | default-eth-for-future | 0.25 | 0 | default-futures |

Given the parties deposit on asset's general account the following amount:
| party | asset | amount |
| a3c024b4e23230c89884a54a813b1ecb4cb0f827a38641c66eeca466da6b2ddf | VEGA | 1000000 |
| aux1 | ETH | 100000000 |
| aux2 | ETH | 100000000 |
| trader3 | ETH | 10000 |
| trader4 | ETH | 10000 |
| lpprov | ETH | 200000000 |
| party1 | ETH | 100000 |
| party2 | ETH | 100000 |
| party3 | ETH | 100000 |
| party4 | ETH | 100000 |


And the parties deposit on staking account the following amount:
| party | asset | amount |
| aux1 | VEGA | 2000 |
| aux2 | VEGA | 800 |
| trader3 | VEGA | 1500 |
| trader4 | VEGA | 1000 |
| lpprov | VEGA | 10000 |
| party1 | VEGA | 2000 |
| party2 | VEGA | 800 |
| party3 | VEGA | 2000 |
| party4 | VEGA | 2000 |


Given time is updated to "2023-09-23T00:00:00Z"
Given the average block duration is "1"

#complete the epoch to advance to a meaningful epoch (can't setup transfer to start at epoch 0)
Then the network moves ahead "1" epochs

When the parties submit the following liquidity provision:
| id | party | market id | commitment amount | fee | lp type |
| lp1 | lpprov | ETH/DEC21 | 90000 | 0.1 | submission |
| lp1 | lpprov | ETH/DEC21 | 90000 | 0.1 | submission |
| lp2 | lpprov | ETH/DEC22 | 90000 | 0.1 | submission |
| lp2 | lpprov | ETH/DEC22 | 90000 | 0.1 | submission |

And the parties place the following pegged iceberg orders:
| party | market id | peak size | minimum visible size | side | pegged reference | volume | offset |
| lpprov | ETH/DEC21 | 90 | 1 | buy | BID | 90 | 10 |
| lpprov | ETH/DEC21 | 90 | 1 | sell | ASK | 90 | 10 |
| lpprov | ETH/DEC22 | 90 | 1 | buy | BID | 90 | 10 |
| lpprov | ETH/DEC22 | 90 | 1 | sell | ASK | 90 | 10 |

Then the parties place the following orders:
| party | market id | side | volume | price | resulting trades | type | tif | reference |
| aux1 | ETH/DEC21 | buy | 10 | 1000 | 0 | TYPE_LIMIT | TIF_GTC | |
| aux2 | ETH/DEC21 | sell | 10 | 1000 | 0 | TYPE_LIMIT | TIF_GTC | |
| aux1 | ETH/DEC21 | buy | 1 | 900 | 0 | TYPE_LIMIT | TIF_GTC | buy1 |
| aux2 | ETH/DEC21 | sell | 1 | 1100 | 0 | TYPE_LIMIT | TIF_GTC | sell1 |
| aux1 | ETH/DEC22 | buy | 1 | 1800 | 0 | TYPE_LIMIT | TIF_GTC | buy2 |
| aux2 | ETH/DEC22 | sell | 1 | 2200 | 0 | TYPE_LIMIT | TIF_GTC | sell2 |

Scenario: If an eligible party has zero net returns, their relative returns reward metric should be zero(0056-REWA-111)
# setup recurring transfer to the reward account - this will start at the end of this epoch
Given the parties submit the following recurring transfers:
| id | from | from_account_type | to | to_account_type | asset | amount | start_epoch | end_epoch | factor | metric | metric_asset | markets | lock_period | window_length | distribution_strategy | entity_scope | individual_scope | staking_requirement | notional_requirement |
| 1 | a3c024b4e23230c89884a54a813b1ecb4cb0f827a38641c66eeca466da6b2ddf | ACCOUNT_TYPE_GENERAL | 0000000000000000000000000000000000000000000000000000000000000000 | ACCOUNT_TYPE_REWARD_RELATIVE_RETURN | VEGA | 10000 | 1 | | 1 | DISPATCH_METRIC_RELATIVE_RETURN | ETH | | 2 | 1 | PRO_RATA | INDIVIDUALS | ALL | 0 | 0 |

Then the network moves ahead "1" epochs

Given time is updated to "2023-09-23T00:00:30Z"
Then the parties place the following orders:
| party | market id | side | volume | price | resulting trades | type | tif | reference |
| party1 | ETH/DEC21 | buy | 10 | 1000 | 0 | TYPE_LIMIT | TIF_GTC | p1-buy1 |
| aux1 | ETH/DEC21 | sell | 10 | 1000 | 1 | TYPE_LIMIT | TIF_GTC | |

Then the parties place the following orders:
| party | market id | side | volume | price | resulting trades | type | tif | reference |
| party2 | ETH/DEC21 | sell | 10 | 1000 | 0 | TYPE_LIMIT | TIF_GTC | p2-sell |
| aux2 | ETH/DEC21 | buy | 10 | 1000 | 1 | TYPE_LIMIT | TIF_GTC | |

Then the network moves ahead "1" epochs

# M2M
# party1 = 0
# aux1 = 0

# relative return metric for party1 = 0
# relative return metric for aux1 = 0
And "a3c024b4e23230c89884a54a813b1ecb4cb0f827a38641c66eeca466da6b2ddf" should have general account balance of "1000000" for asset "VEGA"

Scenario: If a `window_length>1` is specified in the recurring transfer, if an eligible party has zero net returns in all epochs, their relative return metric should be zero(0056-REWA-114)
Given the parties submit the following recurring transfers:
| id | from | from_account_type | to | to_account_type | asset | amount | start_epoch | end_epoch | factor | metric | metric_asset | markets | lock_period | window_length | distribution_strategy | entity_scope | individual_scope | staking_requirement | notional_requirement |
| 1 | a3c024b4e23230c89884a54a813b1ecb4cb0f827a38641c66eeca466da6b2ddf | ACCOUNT_TYPE_GENERAL | 0000000000000000000000000000000000000000000000000000000000000000 | ACCOUNT_TYPE_REWARD_RELATIVE_RETURN | VEGA | 10000 | 1 | | 1 | DISPATCH_METRIC_RELATIVE_RETURN | ETH | | 2 | 6 | PRO_RATA | INDIVIDUALS | ALL | 0 | 0 |

Then the network moves ahead "1" epochs

Given time is updated to "2023-09-23T00:00:30Z"
Then the parties place the following orders:
| party | market id | side | volume | price | resulting trades | type | tif | reference |
| aux1 | ETH/DEC21 | buy | 10 | 1000 | 0 | TYPE_LIMIT | TIF_GTC | p1-buy1 |
| aux2 | ETH/DEC21 | sell | 10 | 1000 | 1 | TYPE_LIMIT | TIF_GTC | |

Then the network moves ahead "1" epochs

# M2M
# party1 = 0
# aux1 = 0
# relative return metric for party1 = 0
# relative return metric for aux1 = 0
And "a3c024b4e23230c89884a54a813b1ecb4cb0f827a38641c66eeca466da6b2ddf" should have general account balance of "1000000" for asset "VEGA"

134 changes: 134 additions & 0 deletions core/integration/features/rewards/0056-REWA-116.feature
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,134 @@
Feature: Relative return rewards

Background:
Given the following network parameters are set:
| name | value |
| reward.asset | VEGA |
| validators.epoch.length | 10s |
| validators.delegation.minAmount | 10 |
| reward.staking.delegation.delegatorShare | 0.883 |
| reward.staking.delegation.minimumValidatorStake | 100 |
| reward.staking.delegation.maxPayoutPerParticipant | 100000 |
| reward.staking.delegation.competitionLevel | 1.1 |
| reward.staking.delegation.minValidators | 5 |
| reward.staking.delegation.optimalStakeMultiplier | 5.0 |
| network.markPriceUpdateMaximumFrequency | 0s |
| limits.markets.maxPeggedOrders | 2 |

Given the fees configuration named "fees-config-1":
| maker fee | infrastructure fee |
| 0.005 | 0.002 |
And the price monitoring named "price-monitoring":
| horizon | probability | auction extension |
| 3600 | 0.99 | 3 |

And the simple risk model named "simple-risk-model-1":
| long | short | max move up | min move down | probability of trading |
| 0.2 | 0.1 | 100 | -100 | 0.1 |


And the markets:
| id | quote name | asset | risk model | margin calculator | auction duration | fees | price monitoring | data source config | linear slippage factor | quadratic slippage factor | sla params |
| ETH/DEC21 | ETH | ETH | simple-risk-model-1 | default-margin-calculator | 2 | fees-config-1 | price-monitoring | default-eth-for-future | 0.25 | 0 | default-futures |
| ETH/DEC22 | ETH | ETH | simple-risk-model-1 | default-margin-calculator | 2 | fees-config-1 | price-monitoring | default-eth-for-future | 0.25 | 0 | default-futures |

Given the parties deposit on asset's general account the following amount:
| party | asset | amount |
| a3c024b4e23230c89884a54a813b1ecb4cb0f827a38641c66eeca466da6b2ddf | VEGA | 1000000 |
| aux1 | ETH | 100000000 |
| aux2 | ETH | 100000000 |
| trader3 | ETH | 10000 |
| trader4 | ETH | 10000 |
| lpprov | ETH | 200000000 |
| party1 | ETH | 100000 |
| party2 | ETH | 100000 |
| party3 | ETH | 100000 |
| party4 | ETH | 100000 |

And the parties deposit on staking account the following amount:
| party | asset | amount |
| aux1 | VEGA | 2000 |
| aux2 | VEGA | 2000 |
| trader3 | VEGA | 1500 |
| trader4 | VEGA | 1000 |
| lpprov | VEGA | 10000 |
| party1 | VEGA | 800 |
| party2 | VEGA | 2000 |
| party3 | VEGA | 2000 |
| party4 | VEGA | 2000 |

Given time is updated to "2023-09-23T00:00:00Z"
Given the average block duration is "1"

#complete the epoch to advance to a meaningful epoch (can't setup transfer to start at epoch 0)
Then the network moves ahead "1" epochs

When the parties submit the following liquidity provision:
| id | party | market id | commitment amount | fee | lp type |
| lp1 | lpprov | ETH/DEC21 | 90000 | 0.1 | submission |
| lp1 | lpprov | ETH/DEC21 | 90000 | 0.1 | submission |
| lp2 | lpprov | ETH/DEC22 | 90000 | 0.1 | submission |
| lp2 | lpprov | ETH/DEC22 | 90000 | 0.1 | submission |

And the parties place the following pegged iceberg orders:
| party | market id | peak size | minimum visible size | side | pegged reference | volume | offset |
| lpprov | ETH/DEC21 | 90 | 1 | buy | BID | 90 | 10 |
| lpprov | ETH/DEC21 | 90 | 1 | sell | ASK | 90 | 10 |
| lpprov | ETH/DEC22 | 90 | 1 | buy | BID | 90 | 10 |
| lpprov | ETH/DEC22 | 90 | 1 | sell | ASK | 90 | 10 |

Then the parties place the following orders:
| party | market id | side | volume | price | resulting trades | type | tif | reference |
| aux1 | ETH/DEC21 | buy | 10 | 1000 | 0 | TYPE_LIMIT | TIF_GTC | |
| aux2 | ETH/DEC21 | sell | 10 | 1000 | 0 | TYPE_LIMIT | TIF_GTC | |
| aux1 | ETH/DEC21 | buy | 1 | 900 | 0 | TYPE_LIMIT | TIF_GTC | buy1 |
| aux2 | ETH/DEC21 | sell | 1 | 1100 | 0 | TYPE_LIMIT | TIF_GTC | sell1 |
| party1 | ETH/DEC22 | buy | 5 | 2000 | 0 | TYPE_LIMIT | TIF_GTC | |
| party2 | ETH/DEC22 | sell | 5 | 2000 | 0 | TYPE_LIMIT | TIF_GTC | |
| aux1 | ETH/DEC22 | buy | 1 | 1800 | 0 | TYPE_LIMIT | TIF_GTC | buy2 |
| aux2 | ETH/DEC22 | sell | 1 | 2200 | 0 | TYPE_LIMIT | TIF_GTC | sell2 |
And the mark price should be "0" for the market "ETH/DEC21"

Scenario: Given a recurring transfer is setup such that all eligible parties have a positive reward score, each parties metric is not offset and parties receive the correct rewards. (0056-REWA-116)
# setup recurring transfer to the reward account - this will start at the end of this epoch
Given the parties submit the following recurring transfers:
| id | from | from_account_type | to | to_account_type | asset | amount | start_epoch | end_epoch | factor | metric | metric_asset | markets | lock_period | window_length | distribution_strategy | entity_scope | individual_scope | staking_requirement | notional_requirement |
| 1 | a3c024b4e23230c89884a54a813b1ecb4cb0f827a38641c66eeca466da6b2ddf | ACCOUNT_TYPE_GENERAL | 0000000000000000000000000000000000000000000000000000000000000000 | ACCOUNT_TYPE_REWARD_RELATIVE_RETURN | VEGA | 10000 | 1 | | 1 | DISPATCH_METRIC_RELATIVE_RETURN | ETH | | 2 | 2 | PRO_RATA | INDIVIDUALS | ALL | 1000 | 0 |

Then the network moves ahead "1" epochs
And the mark price should be "1000" for the market "ETH/DEC21"
Then the trading mode should be "TRADING_MODE_CONTINUOUS" for the market "ETH/DEC21"

Given time is updated to "2023-09-23T00:00:30Z"
Then the parties place the following orders:
| party | market id | side | volume | price | resulting trades | type | tif | reference |
| party1 | ETH/DEC21 | buy | 10 | 1002 | 0 | TYPE_LIMIT | TIF_GTC | p1-buy1 |
| aux1 | ETH/DEC21 | sell | 10 | 1002 | 1 | TYPE_LIMIT | TIF_GTC | |
And the mark price should be "1000" for the market "ETH/DEC21"

Then the parties place the following orders:
| party | market id | side | volume | price | resulting trades | type | tif | reference |
| party2 | ETH/DEC21 | sell | 10 | 999 | 0 | TYPE_LIMIT | TIF_GTC | p2-sell |
| aux2 | ETH/DEC21 | buy | 10 | 999 | 1 | TYPE_LIMIT | TIF_GTC | |
And the mark price should be "1000" for the market "ETH/DEC21"

Then the network moves ahead "1" epochs
And the mark price should be "999" for the market "ETH/DEC21"

# M2M
# party1 = -30
# aux1 = 20
# aux2 = 10
# party1 is not eligible because they don't have sufficient staking
# relative return metric for aux1 = 20/5 = 4
# relative return metric for aux2 = 10/5 = 2
# aux1 gets 10000 * 4/6 = 6666
# aux2 gets 10000 * 2/6 = 3333

And "a3c024b4e23230c89884a54a813b1ecb4cb0f827a38641c66eeca466da6b2ddf" should have general account balance of "990000" for asset "VEGA"
And "aux1" should have vesting account balance of "6666" for asset "VEGA"
And "aux2" should have vesting account balance of "3333" for asset "VEGA"

Then debug trades


Loading
Loading