Skip to content

Commit

Permalink
Merge pull request #9906 from vegaprotocol/fix/return_volume_over_window
Browse files Browse the repository at this point in the history
fix: return running volume over window
  • Loading branch information
jeremyletang authored Oct 26, 2023
2 parents c2cf6b7 + dc0c366 commit 499d179
Show file tree
Hide file tree
Showing 5 changed files with 110 additions and 132 deletions.
76 changes: 33 additions & 43 deletions core/integration/features/0084-VDPR-012.feature
Original file line number Diff line number Diff line change
Expand Up @@ -10,28 +10,28 @@ Feature: At the start of an epoch, each parties volume_discount_factor is reeval
| 0.000001 | 0.1 | 0 | 0 | 1.0 |

Given the liquidity monitoring parameters:
| name | triggering ratio | time window | scaling factor |
| lqm-params | 1.0 | 20s | 1.0 |
| name | triggering ratio | time window | scaling factor |
| lqm-params | 1.0 | 20s | 1.0 |

And the following network parameters are set:
| name | value |
| market.value.windowLength | 60s |
| network.markPriceUpdateMaximumFrequency | 0s |
| limits.markets.maxPeggedOrders | 6 |
| market.auction.minimumDuration | 1 |
| market.fee.factors.infrastructureFee | 0.001 |
| market.fee.factors.makerFee | 0.004 |
| name | value |
| market.value.windowLength | 60s |
| network.markPriceUpdateMaximumFrequency | 0s |
| limits.markets.maxPeggedOrders | 6 |
| market.auction.minimumDuration | 1 |
| market.fee.factors.infrastructureFee | 0.001 |
| market.fee.factors.makerFee | 0.004 |

#risk factor short:3.5569036
#risk factor long:0.801225765
And the volume discount program tiers named "VDP-01":
| volume | factor |
| 1000 | 0.001 |
| 2000 | 0.005 |
| 3000 | 0.010 |
| volume | factor |
| 1000 | 0.001 |
| 2000 | 0.005 |
| 3000 | 0.010 |
And the volume discount program:
| id | tiers | closing timestamp | window length |
| id1 | VDP-01 | 0 | 4 |
| id | tiers | closing timestamp | window length |
| id1 | VDP-01 | 0 | 4 |

And the following assets are registered:
| id | decimal places |
Expand All @@ -52,29 +52,29 @@ Feature: At the start of an epoch, each parties volume_discount_factor is reeval
| ETH/MAR24 | ETH | ETH | lqm-params | log-normal-risk-model | margin-calculator-1 | 2 | fees-config-1 | price-monitoring | default-eth-for-future | 1e0 | 0 | SLA-22 |

And the following network parameters are set:
| name | value |
| market.liquidity.bondPenaltyParameter | 0.2 |
| validators.epoch.length | 5s |
| market.liquidity.stakeToCcyVolume | 1 |
| market.liquidity.successorLaunchWindowLength | 1h |
| market.liquidity.sla.nonPerformanceBondPenaltySlope | 0.7 |
| market.liquidity.sla.nonPerformanceBondPenaltyMax | 0.6 |
| validators.epoch.length | 10s |
| market.liquidity.earlyExitPenalty | 0.25 |
| name | value |
| market.liquidity.bondPenaltyParameter | 0.2 |
| validators.epoch.length | 5s |
| market.liquidity.stakeToCcyVolume | 1 |
| market.liquidity.successorLaunchWindowLength | 1h |
| market.liquidity.sla.nonPerformanceBondPenaltySlope | 0.7 |
| market.liquidity.sla.nonPerformanceBondPenaltyMax | 0.6 |
| validators.epoch.length | 10s |
| market.liquidity.earlyExitPenalty | 0.25 |

Given the average block duration is "1"
@Now
Scenario: 001: Check that the volume discount factor is updated after each epoch
Given the parties deposit on asset's general account the following amount:
| party | asset | amount |
| party | asset | amount |
| lp1 | ETH | 10000000 |
| party1 | ETH | 10000000 |
| party2 | ETH | 10000000 |
| party3 | ETH | 10000000 |

And the parties submit the following liquidity provision:
| id | party | market id | commitment amount | fee | lp type |
| lp_1 | lp1 | ETH/MAR24 | 100000 | 0.02 | submission |
| id | party | market id | commitment amount | fee | lp type |
| lp_1 | lp1 | ETH/MAR24 | 100000 | 0.02 | submission |

Then the parties place the following orders:
| party | market id | side | volume | price | resulting trades | type | tif |
Expand All @@ -95,25 +95,15 @@ Feature: At the start of an epoch, each parties volume_discount_factor is reeval
And the party "party3" has the following discount factor "0"

Then the parties place the following orders:
| party | market id | side | volume | price | resulting trades | type | tif |
| party3 | ETH/MAR24 | buy | 2 | 0 | 1 | TYPE_MARKET | TIF_IOC |
| party3 | ETH/MAR24 | sell | 2 | 0 | 1 | TYPE_MARKET | TIF_IOC |
And the market data for the market "ETH/MAR24" should be:
| mark price | trading mode | horizon | min bound | max bound | target stake | supplied stake | open interest |
| 1000 | TRADING_MODE_CONTINUOUS | 3600 | 973 | 1027 | 10670 | 100000 | 1 |
When the network moves ahead "1" epochs
And the party "party3" has the following discount factor "0.001"

Then the parties place the following orders:
| party | market id | side | volume | price | resulting trades | type | tif |
| party3 | ETH/MAR24 | buy | 2 | 0 | 1 | TYPE_MARKET | TIF_IOC |
| party3 | ETH/MAR24 | sell | 2 | 0 | 1 | TYPE_MARKET | TIF_IOC |
| party | market id | side | volume | price | resulting trades | type | tif |
| party3 | ETH/MAR24 | buy | 1 | 0 | 1 | TYPE_MARKET | TIF_IOC |
| party3 | ETH/MAR24 | sell | 1 | 0 | 1 | TYPE_MARKET | TIF_IOC |
When the network moves ahead "1" epochs
And the party "party3" has the following discount factor "0.005"

Then the parties place the following orders:
| party | market id | side | volume | price | resulting trades | type | tif |
| party3 | ETH/MAR24 | buy | 20 | 0 | 1 | TYPE_MARKET | TIF_IOC |
| party3 | ETH/MAR24 | sell | 20 | 0 | 1 | TYPE_MARKET | TIF_IOC |
| party | market id | side | volume | price | resulting trades | type | tif |
| party3 | ETH/MAR24 | buy | 20 | 0 | 1 | TYPE_MARKET | TIF_IOC |
| party3 | ETH/MAR24 | sell | 20 | 0 | 1 | TYPE_MARKET | TIF_IOC |
When the network moves ahead "1" epochs
And the party "party3" has the following discount factor "0.01"
31 changes: 10 additions & 21 deletions core/integration/features/0084-VDPR-013.feature
Original file line number Diff line number Diff line change
Expand Up @@ -98,29 +98,18 @@ Feature: A parties volume_discount_factor is set equal to the factors in the hig

Then the parties place the following orders:
| party | market id | side | volume | price | resulting trades | type | tif |
| party3 | ETH/MAR24 | buy | 3 | 0 | 1 | TYPE_MARKET | TIF_IOC |
| party3 | ETH/MAR24 | sell | 3 | 0 | 1 | TYPE_MARKET | TIF_IOC |
And the market data for the market "ETH/MAR24" should be:
| mark price | trading mode | horizon | min bound | max bound | target stake | supplied stake | open interest |
| 1000 | TRADING_MODE_CONTINUOUS | 3600 | 973 | 1027 | 14227 | 100000 | 1 |
| party3 | ETH/MAR24 | buy | 1 | 0 | 1 | TYPE_MARKET | TIF_IOC |
| party3 | ETH/MAR24 | sell | 1 | 0 | 1 | TYPE_MARKET | TIF_IOC |
When the network moves ahead "1" epochs
And the party "party3" has the following taker notional "1500"
And the party "party3" has the following discount factor "0.01"

Then the parties place the following orders:
| party | market id | side | volume | price | resulting trades | type | tif |
| party3 | ETH/MAR24 | buy | 2 | 0 | 1 | TYPE_MARKET | TIF_IOC |
| party3 | ETH/MAR24 | sell | 2 | 0 | 1 | TYPE_MARKET | TIF_IOC |
When the network moves ahead "1" epochs
And the party "party3" has the following taker notional "2500"
And the party "party3" has the following taker notional "2000"
And the party "party3" has the following discount factor "0.02"

Then the parties place the following orders:
| party | market id | side | volume | price | resulting trades | type | tif |
| party3 | ETH/MAR24 | buy | 5 | 0 | 1 | TYPE_MARKET | TIF_IOC |
| party3 | ETH/MAR24 | sell | 5 | 0 | 1 | TYPE_MARKET | TIF_IOC |
| party3 | ETH/MAR24 | buy | 1 | 0 | 1 | TYPE_MARKET | TIF_IOC |
| party3 | ETH/MAR24 | sell | 1 | 0 | 1 | TYPE_MARKET | TIF_IOC |
When the network moves ahead "1" epochs
And the party "party3" has the following taker notional "5000"
And the party "party3" has the following taker notional "4000"
And the party "party3" has the following discount factor "0.03"

# now that party3 has a discount, lets do a trade with fees
Expand Down Expand Up @@ -152,7 +141,7 @@ Feature: A parties volume_discount_factor is set equal to the factors in the hig
| party3 | ETH/MAR24 | sell | 100 | 1000 | 0 | TYPE_LIMIT | TIF_GTC |

And the parties submit the following liquidity provision:
| id | party | market id | commitment amount | fee | lp type |
| id | party | market id | commitment amount | fee | lp type |
| lp1 | lp1 | ETH/MAR24 | 1000000 | 0.02 | submission |
When the network moves ahead "1" epochs
Then the trading mode should be "TRADING_MODE_CONTINUOUS" for the market "ETH/MAR24"
Expand All @@ -161,6 +150,6 @@ Feature: A parties volume_discount_factor is set equal to the factors in the hig
# infra fee discount - floor(50 *0.03) = 1
# no lp fee
Then the following transfers should happen:
| from | to | from account | to account | market id | amount | asset |
| party3 | | ACCOUNT_TYPE_GENERAL | ACCOUNT_TYPE_FEES_INFRASTRUCTURE | | 49 | ETH |
| party1 | | ACCOUNT_TYPE_GENERAL | ACCOUNT_TYPE_FEES_INFRASTRUCTURE | | 50 | ETH |
| from | to | from account | to account | market id | amount | asset |
| party3 | | ACCOUNT_TYPE_GENERAL | ACCOUNT_TYPE_FEES_INFRASTRUCTURE | | 49 | ETH |
| party1 | | ACCOUNT_TYPE_GENERAL | ACCOUNT_TYPE_FEES_INFRASTRUCTURE | | 50 | ETH |
62 changes: 31 additions & 31 deletions core/integration/features/0084-VDPR-014.feature
Original file line number Diff line number Diff line change
Expand Up @@ -9,27 +9,27 @@ Feature: If a party does not qualify for the lowest tier, their volume_discount_
| risk aversion | tau | mu | r | sigma |
| 0.000001 | 0.1 | 0 | 0 | 1.0 |
Given the liquidity monitoring parameters:
| name | triggering ratio | time window | scaling factor |
| lqm-params | 1.0 | 20s | 1.0 |
| name | triggering ratio | time window | scaling factor |
| lqm-params | 1.0 | 20s | 1.0 |
And the following network parameters are set:
| name | value |
| market.value.windowLength | 60s |
| network.markPriceUpdateMaximumFrequency | 0s |
| limits.markets.maxPeggedOrders | 6 |
| market.auction.minimumDuration | 1 |
| market.fee.factors.infrastructureFee | 0.001 |
| market.fee.factors.makerFee | 0.004 |
| name | value |
| market.value.windowLength | 60s |
| network.markPriceUpdateMaximumFrequency | 0s |
| limits.markets.maxPeggedOrders | 6 |
| market.auction.minimumDuration | 1 |
| market.fee.factors.infrastructureFee | 0.001 |
| market.fee.factors.makerFee | 0.004 |

#risk factor short:3.5569036
#risk factor long:0.801225765
And the volume discount program tiers named "VDP-01":
| volume | factor |
| 1000 | 0.01 |
| 2000 | 0.02 |
| 3000 | 0.03 |
| volume | factor |
| 3000 | 0.01 |
| 4000 | 0.02 |
| 5000 | 0.03 |
And the volume discount program:
| id | tiers | closing timestamp | window length |
| id1 | VDP-01 | 0 | 4 |
| id | tiers | closing timestamp | window length |
| id1 | VDP-01 | 0 | 4 |

And the following assets are registered:
| id | decimal places |
Expand All @@ -50,29 +50,29 @@ Feature: If a party does not qualify for the lowest tier, their volume_discount_
| ETH/MAR24 | ETH | ETH | lqm-params | log-normal-risk-model | margin-calculator-1 | 2 | fees-config-1 | price-monitoring | default-eth-for-future | 1e0 | 0 | SLA-22 |

And the following network parameters are set:
| name | value |
| market.liquidity.bondPenaltyParameter | 0.2 |
| validators.epoch.length | 5s |
| market.liquidity.stakeToCcyVolume | 1 |
| market.liquidity.successorLaunchWindowLength | 1h |
| market.liquidity.sla.nonPerformanceBondPenaltySlope | 0.7 |
| market.liquidity.sla.nonPerformanceBondPenaltyMax | 0.6 |
| validators.epoch.length | 10s |
| market.liquidity.earlyExitPenalty | 0.25 |
| name | value |
| market.liquidity.bondPenaltyParameter | 0.2 |
| validators.epoch.length | 5s |
| market.liquidity.stakeToCcyVolume | 1 |
| market.liquidity.successorLaunchWindowLength | 1h |
| market.liquidity.sla.nonPerformanceBondPenaltySlope | 0.7 |
| market.liquidity.sla.nonPerformanceBondPenaltyMax | 0.6 |
| validators.epoch.length | 10s |
| market.liquidity.earlyExitPenalty | 0.25 |

Given the average block duration is "1"
@Now
Scenario: 001: If a trader doesn't touch or pass the first tier, they get no discount
Given the parties deposit on asset's general account the following amount:
| party | asset | amount |
| party | asset | amount |
| lp1 | ETH | 10000000 |
| party1 | ETH | 10000000 |
| party2 | ETH | 10000000 |
| party3 | ETH | 10000000 |

And the parties submit the following liquidity provision:
| id | party | market id | commitment amount | fee | lp type |
| lp_1 | lp1 | ETH/MAR24 | 100000 | 0.02 | submission |
| id | party | market id | commitment amount | fee | lp type |
| lp_1 | lp1 | ETH/MAR24 | 100000 | 0.02 | submission |

Then the parties place the following orders:
| party | market id | side | volume | price | resulting trades | type | tif |
Expand All @@ -94,14 +94,14 @@ Feature: If a party does not qualify for the lowest tier, their volume_discount_
And the party "party3" has the following discount factor "0"

Then the parties place the following orders:
| party | market id | side | volume | price | resulting trades | type | tif |
| party3 | ETH/MAR24 | buy | 1 | 0 | 1 | TYPE_MARKET | TIF_IOC |
| party3 | ETH/MAR24 | sell | 1 | 0 | 1 | TYPE_MARKET | TIF_IOC |
| party | market id | side | volume | price | resulting trades | type | tif |
| party3 | ETH/MAR24 | buy | 1 | 0 | 1 | TYPE_MARKET | TIF_IOC |
| party3 | ETH/MAR24 | sell | 1 | 0 | 1 | TYPE_MARKET | TIF_IOC |
And the market data for the market "ETH/MAR24" should be:
| mark price | trading mode | horizon | min bound | max bound | target stake | supplied stake | open interest |
| 1000 | TRADING_MODE_CONTINUOUS | 3600 | 973 | 1027 | 7113 | 100000 | 1 |
When the network moves ahead "1" epochs
# The taker trades above are not enough for party3 to hit the first level of the discount tier
# so we get a zero for the discount factor
And the party "party3" has the following taker notional "500"
And the party "party3" has the following taker notional "2000"
And the party "party3" has the following discount factor "0"
3 changes: 1 addition & 2 deletions core/volumediscount/engine.go
Original file line number Diff line number Diff line change
Expand Up @@ -155,7 +155,6 @@ func (e *Engine) notifyVolumeDiscountProgramEnded(ctx context.Context, epochTime
}

func (e *Engine) calculatePartiesVolumeForWindow(windowSize int) {
windowSizeAsDecimal := num.DecimalFromInt64(int64(windowSize))
for pi := range e.parties {
total := num.UintZero()
for i := 0; i < windowSize; i++ {
Expand All @@ -165,7 +164,7 @@ func (e *Engine) calculatePartiesVolumeForWindow(windowSize int) {
}
total.AddSum(valueForEpoch)
}
e.avgVolumePerParty[pi] = total.ToDecimal().Div(windowSizeAsDecimal)
e.avgVolumePerParty[pi] = total.ToDecimal()
}
}

Expand Down
Loading

0 comments on commit 499d179

Please sign in to comment.