code.vegaprotocol.io/vega@v0.79.0/core/integration/features/amm/11504-rounding.feature (about) 1 Feature: Ensure rounding errors do not cause empty curve panic. 2 3 Background: 4 Given the average block duration is "1" 5 And the margin calculator named "margin-calculator-1": 6 | search factor | initial factor | release factor | 7 | 1.2 | 1.5 | 1.7 | 8 And the log normal risk model named "log-normal-risk-model": 9 | risk aversion | tau | mu | r | sigma | 10 | 0.001 | 0.0011407711613050422 | 0 | 0.9 | 3.0 | 11 And the liquidity monitoring parameters: 12 | name | triggering ratio | time window | scaling factor | 13 | lqm-params | 1.00 | 20s | 1 | 14 15 And the following network parameters are set: 16 | name | value | 17 | market.value.windowLength | 60s | 18 | network.markPriceUpdateMaximumFrequency | 0s | 19 | limits.markets.maxPeggedOrders | 6 | 20 | market.auction.minimumDuration | 1 | 21 | market.fee.factors.infrastructureFee | 0.001 | 22 | market.fee.factors.makerFee | 0.004 | 23 | spam.protection.max.stopOrdersPerMarket | 5 | 24 | market.liquidity.equityLikeShareFeeFraction | 1 | 25 | market.amm.minCommitmentQuantum | 1000 | 26 | market.liquidity.bondPenaltyParameter | 0.2 | 27 | market.liquidity.stakeToCcyVolume | 1 | 28 | market.liquidity.successorLaunchWindowLength | 1h | 29 | market.liquidity.sla.nonPerformanceBondPenaltySlope | 0.1 | 30 | market.liquidity.sla.nonPerformanceBondPenaltyMax | 0.6 | 31 | validators.epoch.length | 10s | 32 | market.liquidity.earlyExitPenalty | 0.25 | 33 | market.liquidity.maximumLiquidityFeeFactorLevel | 0.25 | 34 #risk factor short:3.5569036 35 #risk factor long:0.801225765 36 And the following assets are registered: 37 | id | decimal places | 38 | USD | 0 | 39 And the fees configuration named "fees-config-1": 40 | maker fee | infrastructure fee | 41 | 0.0004 | 0.001 | 42 43 And the liquidity sla params named "SLA-22": 44 | price range | commitment min time fraction | performance hysteresis epochs | sla competition factor | 45 | 0.5 | 0.6 | 1 | 1.0 | 46 47 And the markets: 48 | id | quote name | asset | liquidity monitoring | risk model | margin calculator | auction duration | fees | price monitoring | data source config | linear slippage factor | quadratic slippage factor | sla params | 49 | ETH/MAR22 | USD | USD | lqm-params | log-normal-risk-model | margin-calculator-1 | 2 | fees-config-1 | default-none | default-eth-for-future | 1e0 | 0 | SLA-22 | 50 51 # Setting up the accounts and vAMM submission now is part of the background, because we'll be running scenarios 0090-VAMM-006 through 0090-VAMM-014 on this setup 52 Given the parties deposit on asset's general account the following amount: 53 | party | asset | amount | 54 | lp1 | USD | 1000000 | 55 | lp2 | USD | 1000000 | 56 | lp3 | USD | 1000000 | 57 | party1 | USD | 1000000 | 58 | party2 | USD | 1000000 | 59 | party3 | USD | 1000000 | 60 | party4 | USD | 1000000 | 61 | party5 | USD | 1000000 | 62 | vamm1 | USD | 30000 | 63 | vamm2 | USD | 30000 | 64 65 When the parties submit the following liquidity provision: 66 | id | party | market id | commitment amount | fee | lp type | 67 | lp_1 | lp1 | ETH/MAR22 | 600 | 0.02 | submission | 68 | lp_2 | lp2 | ETH/MAR22 | 400 | 0.015 | submission | 69 Then the network moves ahead "4" blocks 70 And the current epoch is "0" 71 72 And the parties place the following orders: 73 | party | market id | side | volume | price | resulting trades | type | tif | reference | 74 | lp1 | ETH/MAR22 | buy | 20 | 40 | 0 | TYPE_LIMIT | TIF_GTC | lp1-b | 75 | party1 | ETH/MAR22 | buy | 1 | 100 | 0 | TYPE_LIMIT | TIF_GTC | | 76 | party2 | ETH/MAR22 | sell | 1 | 100 | 0 | TYPE_LIMIT | TIF_GTC | | 77 | lp1 | ETH/MAR22 | sell | 10 | 160 | 0 | TYPE_LIMIT | TIF_GTC | lp1-s | 78 When the opening auction period ends for market "ETH/MAR22" 79 Then the following trades should be executed: 80 | buyer | price | size | seller | 81 | party1 | 100 | 1 | party2 | 82 83 And the market data for the market "ETH/MAR22" should be: 84 | mark price | trading mode | target stake | supplied stake | open interest | ref price | mid price | static mid price | 85 | 100 | TRADING_MODE_CONTINUOUS | 39 | 1000 | 1 | 100 | 100 | 100 | 86 When the parties submit the following AMM: 87 | party | market id | amount | slippage | base | lower bound | upper bound | lower leverage | upper leverage | proposed fee | 88 | vamm1 | ETH/MAR22 | 30000 | 0.1 | 100 | 85 | 150 | 4 | 4 | 0.01 | 89 | vamm2 | ETH/MAR22 | 30000 | 0.1 | 100 | 85 | 150 | 4 | 4 | 0.01 | 90 Then the AMM pool status should be: 91 | party | market id | amount | status | base | lower bound | upper bound | lower leverage | upper leverage | 92 | vamm1 | ETH/MAR22 | 30000 | STATUS_ACTIVE | 100 | 85 | 150 | 4 | 4 | 93 | vamm2 | ETH/MAR22 | 30000 | STATUS_ACTIVE | 100 | 85 | 150 | 4 | 4 | 94 95 And set the following AMM sub account aliases: 96 | party | market id | alias | 97 | vamm1 | ETH/MAR22 | vamm1-id | 98 | vamm2 | ETH/MAR22 | vamm2-id | 99 And the following transfers should happen: 100 | from | from account | to | to account | market id | amount | asset | is amm | type | 101 | vamm1 | ACCOUNT_TYPE_GENERAL | vamm1-id | ACCOUNT_TYPE_GENERAL | | 30000 | USD | true | TRANSFER_TYPE_AMM_LOW | 102 | vamm2 | ACCOUNT_TYPE_GENERAL | vamm2-id | ACCOUNT_TYPE_GENERAL | | 30000 | USD | true | TRANSFER_TYPE_AMM_LOW | 103 104 @VAMM 105 Scenario: both AMMs trade with a given order, the amount traded is distributed pro-rata. 106 # Volume is 5, divided by 2 -> 1 party will trade 3, one will trade 2. 107 When the parties place the following orders: 108 | party | market id | side | volume | price | resulting trades | type | tif | 109 | party4 | ETH/MAR22 | buy | 5 | 120 | 2 | TYPE_LIMIT | TIF_GTC | 110 # see the trades that make the vAMM go short 111 112 Then the following trades should be executed: 113 | buyer | price | size | seller | is amm | 114 | party4 | 100 | 3 | vamm1-id | true | 115 | party4 | 100 | 2 | vamm2-id | true | 116 117 When the network moves ahead "1" blocks 118 Then the market data for the market "ETH/MAR22" should be: 119 | mark price | trading mode | mid price | static mid price | 120 | 100 | TRADING_MODE_CONTINUOUS | 101 | 101 | 121 And the parties should have the following profit and loss: 122 | party | volume | unrealised pnl | realised pnl | is amm | 123 | party4 | 5 | 0 | 0 | | 124 | vamm1-id | -3 | 0 | 0 | true | 125 | vamm2-id | -2 | 0 | 0 | true | 126 And the AMM pool status should be: 127 | party | market id | amount | status | base | lower bound | upper bound | lower leverage | upper leverage | 128 | vamm1 | ETH/MAR22 | 30000 | STATUS_ACTIVE | 100 | 85 | 150 | 4 | 4 | 129 | vamm2 | ETH/MAR22 | 30000 | STATUS_ACTIVE | 100 | 85 | 150 | 4 | 4 | 130 131 # Now submit another order, the available volumes ought to be the other way around, the positions equal out. 132 When the parties place the following orders: 133 | party | market id | side | volume | price | resulting trades | type | tif | 134 | party4 | ETH/MAR22 | buy | 31 | 110 | 2 | TYPE_LIMIT | TIF_GTC | 135 Then the following trades should be executed: 136 | buyer | price | size | seller | is amm | 137 | party4 | 105 | 16 | vamm1-id | true | 138 | party4 | 104 | 15 | vamm2-id | true | 139 When the network moves ahead "1" blocks 140 Then the market data for the market "ETH/MAR22" should be: 141 | mark price | trading mode | mid price | static mid price | 142 | 104 | TRADING_MODE_CONTINUOUS | 108 | 108 | 143 And the parties should have the following profit and loss: 144 | party | volume | unrealised pnl | realised pnl | is amm | 145 | party4 | 36 | 4 | 0 | | 146 | vamm1-id | -19 | 4 | 0 | true | 147 | vamm2-id | -17 | -8 | 0 | true |