code.vegaprotocol.io/vega@v0.79.0/core/integration/features/transfers/one_off_transfers_fee_discount.feature (about) 1 Feature: Test fee discounts for one off transfers 2 3 Background: 4 Given time is updated to "2021-08-26T00:00:00Z" 5 And the following network parameters are set: 6 | name | value | 7 | transfer.fee.factor | 0.5 | 8 | market.fee.factors.makerFee | 0.004 | 9 | market.fee.factors.infrastructureFee | 0.002 | 10 | network.markPriceUpdateMaximumFrequency | 0s | 11 | transfer.fee.maxQuantumAmount | 100000 | 12 | transfer.feeDiscountDecayFraction | 0.9 | 13 And the markets: 14 | id | quote name | asset | risk model | margin calculator | auction duration | fees | price monitoring | data source config | linear slippage factor | quadratic slippage factor | sla params | 15 | ETH/DEC19 | ETH | ETH | default-simple-risk-model-2 | default-margin-calculator | 1 | default-none | default-none | default-eth-for-future | 0.25 | 0 | default-futures | 16 And the following network parameters are set: 17 | name | value | 18 | market.auction.minimumDuration | 1 | 19 | limits.markets.maxPeggedOrders | 1500 | 20 | network.markPriceUpdateMaximumFrequency | 0s | 21 22 And the parties deposit on asset's general account the following amount: 23 | party | asset | amount | 24 | a7c4b181ef9bf5e9029a016f854e4ad471208020fd86187d07f0b420004f06a4 | ETH | 100000000000 | 25 | f0b40ebdc5b92cf2cf82ff5d0c3f94085d23d5ec2d37d0b929e177c6d4d37e4c | ETH | 100000000000 | 26 27 When the parties deposit on asset's general account the following amount: 28 | party | asset | amount | 29 | aux | ETH | 100000000000 | 30 | aux2 | ETH | 100000000000 | 31 | lpprov | ETH | 100000000000 | 32 | tx_to_party | ETH | 100000000000 | 33 Then the parties submit the following liquidity provision: 34 | id | party | market id | commitment amount | fee | lp type | 35 | lp1 | lpprov | ETH/DEC19 | 10000000 | 0.001 | submission | 36 # move market to continuous 37 And the parties place the following orders: 38 | party | market id | side | volume | price | resulting trades | type | tif | 39 | lpprov | ETH/DEC19 | buy | 1000 | 970 | 0 | TYPE_LIMIT | TIF_GTC | 40 | aux2 | ETH/DEC19 | buy | 1 | 1000 | 0 | TYPE_LIMIT | TIF_GTC | 41 | aux | ETH/DEC19 | sell | 1 | 1000 | 0 | TYPE_LIMIT | TIF_GTC | 42 | lpprov | ETH/DEC19 | sell | 1000 | 1035 | 0 | TYPE_LIMIT | TIF_GTC | 43 And the opening auction period ends for market "ETH/DEC19" 44 And the trading mode should be "TRADING_MODE_CONTINUOUS" for the market "ETH/DEC19" 45 46 Given the parties place the following orders: 47 | party | market id | side | volume | price | resulting trades | type | tif | 48 | a7c4b181ef9bf5e9029a016f854e4ad471208020fd86187d07f0b420004f06a4 | ETH/DEC19 | buy | 1000 | 1000 | 0 | TYPE_LIMIT | TIF_GTC | 49 | f0b40ebdc5b92cf2cf82ff5d0c3f94085d23d5ec2d37d0b929e177c6d4d37e4c | ETH/DEC19 | sell | 1000 | 1000 | 1 | TYPE_LIMIT | TIF_GTC | 50 When the network moves ahead "1" epochs 51 Then the following transfers should happen: 52 | from | to | from account | to account | market id | amount | asset | 53 | f0b40ebdc5b92cf2cf82ff5d0c3f94085d23d5ec2d37d0b929e177c6d4d37e4c | market | ACCOUNT_TYPE_GENERAL | ACCOUNT_TYPE_FEES_MAKER | ETH/DEC19 | 4000 | ETH | 54 | f0b40ebdc5b92cf2cf82ff5d0c3f94085d23d5ec2d37d0b929e177c6d4d37e4c | market | ACCOUNT_TYPE_GENERAL | ACCOUNT_TYPE_FEES_INFRASTRUCTURE | | 2000 | ETH | 55 | f0b40ebdc5b92cf2cf82ff5d0c3f94085d23d5ec2d37d0b929e177c6d4d37e4c | market | ACCOUNT_TYPE_GENERAL | ACCOUNT_TYPE_FEES_LIQUIDITY | ETH/DEC19 | 1000 | ETH | 56 | market | a7c4b181ef9bf5e9029a016f854e4ad471208020fd86187d07f0b420004f06a4 | ACCOUNT_TYPE_FEES_MAKER | ACCOUNT_TYPE_GENERAL | ETH/DEC19 | 4000 | ETH | 57 58 59 @transfer @fee-discount 60 Scenario: 0057-TRAN-021 when a party paid taker fee g in previous epoch, and transfer.feeDiscountDecayFraction = 0.9, then in the next epoch when a party (did not generate any fees) makes a transfer and the theoretical fee the party should pay is f, fee-free amount is then c = 0.9 x g. If c > f, then no transfer fee is paid. And a party makes another transfer, and the theoretical fee the party should pay is f, then the party is not getting any fee-free discount 61 # fee free discount total = 400000 + 200000 + 100000 62 Given the parties have the following transfer fee discounts: 63 | party | asset | available discount | 64 | f0b40ebdc5b92cf2cf82ff5d0c3f94085d23d5ec2d37d0b929e177c6d4d37e4c | ETH | 7000 | 65 66 # assert decay is 7000 * 0.9 67 When the network moves ahead "1" epochs 68 Then the parties have the following transfer fee discounts: 69 | party | asset | available discount | 70 | f0b40ebdc5b92cf2cf82ff5d0c3f94085d23d5ec2d37d0b929e177c6d4d37e4c | ETH | 6300 | 71 72 # transfer depletes fees discount total 73 Given the parties submit the following one off transfers: 74 | id | from | from_account_type | to | to_account_type | asset | amount | delivery_time | 75 | 1 | f0b40ebdc5b92cf2cf82ff5d0c3f94085d23d5ec2d37d0b929e177c6d4d37e4c | ACCOUNT_TYPE_GENERAL | a7c4b181ef9bf5e9029a016f854e4ad471208020fd86187d07f0b420004f06a4 | ACCOUNT_TYPE_GENERAL | ETH | 12600 | 2021-08-26T00:00:10Z | 76 And time is updated to "2021-08-26T00:00:10Z" 77 When the parties have the following transfer fee discounts: 78 | party | asset | available discount | 79 | f0b40ebdc5b92cf2cf82ff5d0c3f94085d23d5ec2d37d0b929e177c6d4d37e4c | ETH | 0 | 80 Then the following transfers should happen: 81 | from | to | from account | to account | market id | amount | asset | 82 | f0b40ebdc5b92cf2cf82ff5d0c3f94085d23d5ec2d37d0b929e177c6d4d37e4c | market | ACCOUNT_TYPE_GENERAL | ACCOUNT_TYPE_FEES_INFRASTRUCTURE | | 0 | ETH | 83 84 # one more transfer that will incur fees 85 Given the parties submit the following one off transfers: 86 | id | from | from_account_type | to | to_account_type | asset | amount | delivery_time | 87 | 1 | f0b40ebdc5b92cf2cf82ff5d0c3f94085d23d5ec2d37d0b929e177c6d4d37e4c | ACCOUNT_TYPE_GENERAL | a7c4b181ef9bf5e9029a016f854e4ad471208020fd86187d07f0b420004f06a4 | ACCOUNT_TYPE_GENERAL | ETH | 10000 | 2021-08-26T00:00:10Z | 88 When the parties have the following transfer fee discounts: 89 | party | asset | available discount | 90 | f0b40ebdc5b92cf2cf82ff5d0c3f94085d23d5ec2d37d0b929e177c6d4d37e4c | ETH | 0 | 91 Then the following transfers should happen: 92 | from | to | from account | to account | market id | amount | asset | 93 | f0b40ebdc5b92cf2cf82ff5d0c3f94085d23d5ec2d37d0b929e177c6d4d37e4c | market | ACCOUNT_TYPE_GENERAL | ACCOUNT_TYPE_FEES_INFRASTRUCTURE | | 5000 | ETH | 94 95 @transfer @fee-discount 96 Scenario: 0057-TRAN-020 and 0057-TRAN-022 when a party made maker fee g in previous epoch, and transfer.feeDiscountDecayFraction = 0.9, then in the next epoch when a party (did not generate any fees) makes a transfer and the theoretical fee the party should pay is f, fee-free amount is then c = 0.9 x g. If c > f, then no transfer fee is paid. And a party makes another transfer, and the theoretical fee the party should pay is f, then the party is not getting any fee-free discount 97 # 0057-TRAN-020: when a party made maker fee g in previous epoch, and transfer.feeDiscountDecayFraction = 0.9, then in the next epoch when a party (did not generate any fees) makes a transfer and the theoretical fee the party should pay is f, fee-free amount is then c = 0.9 x g. If c > f, then no transfer fee is paid 98 # fee free discount total = maker fees made = 4000 99 Given the parties have the following transfer fee discounts: 100 | party | asset | available discount | 101 | a7c4b181ef9bf5e9029a016f854e4ad471208020fd86187d07f0b420004f06a4 | ETH | 4000 | 102 103 # assert decay is 7000 * 0.9 104 When the network moves ahead "1" epochs 105 Then the parties have the following transfer fee discounts: 106 | party | asset | available discount | 107 | a7c4b181ef9bf5e9029a016f854e4ad471208020fd86187d07f0b420004f06a4 | ETH | 3600 | 108 109 # transfer depletes fees discount total 0057-TRAN-020 110 Given the parties submit the following one off transfers: 111 | id | from | from_account_type | to | to_account_type | asset | amount | delivery_time | 112 | 1 | a7c4b181ef9bf5e9029a016f854e4ad471208020fd86187d07f0b420004f06a4 | ACCOUNT_TYPE_GENERAL | f0b40ebdc5b92cf2cf82ff5d0c3f94085d23d5ec2d37d0b929e177c6d4d37e4c | ACCOUNT_TYPE_GENERAL | ETH | 7200 | 2021-08-26T00:00:10Z | 113 And time is updated to "2021-08-26T00:00:10Z" 114 When the parties have the following transfer fee discounts: 115 | party | asset | available discount | 116 | a7c4b181ef9bf5e9029a016f854e4ad471208020fd86187d07f0b420004f06a4 | ETH | 0 | 117 Then the following transfers should happen: 118 | from | to | from account | to account | market id | amount | asset | 119 | a7c4b181ef9bf5e9029a016f854e4ad471208020fd86187d07f0b420004f06a4 | market | ACCOUNT_TYPE_GENERAL | ACCOUNT_TYPE_FEES_INFRASTRUCTURE | | 0 | ETH | 120 121 # now we have used up the fee discount, one more transfer that will incur fees 0057-TRAN-022 122 Given the parties submit the following one off transfers: 123 | id | from | from_account_type | to | to_account_type | asset | amount | delivery_time | 124 | 1 | a7c4b181ef9bf5e9029a016f854e4ad471208020fd86187d07f0b420004f06a4 | ACCOUNT_TYPE_GENERAL | f0b40ebdc5b92cf2cf82ff5d0c3f94085d23d5ec2d37d0b929e177c6d4d37e4c | ACCOUNT_TYPE_GENERAL | ETH | 10000 | 2021-08-26T00:00:10Z | 125 When the parties have the following transfer fee discounts: 126 | party | asset | available discount | 127 | a7c4b181ef9bf5e9029a016f854e4ad471208020fd86187d07f0b420004f06a4 | ETH | 0 | 128 Then the following transfers should happen: 129 | from | to | from account | to account | market id | amount | asset | 130 | a7c4b181ef9bf5e9029a016f854e4ad471208020fd86187d07f0b420004f06a4 | market | ACCOUNT_TYPE_GENERAL | ACCOUNT_TYPE_FEES_INFRASTRUCTURE | | 5000 | ETH | 131 132 @transfer @fee-discount 133 Scenario: 0057-TRAN-027 when a party makes a transfer and f would be the theoretical fee the party should pay then the fee on the transfer that is actually charged is -min(f-c,0). The system subsequently updates c <- max(0,c-f). At the end of epoch, update c <- c x D and c <- c + all_trading_fees_for_trades_involved_in, if c < M x quantum(M is transfer.feeDiscountMinimumTrackedAmount), then set c <- 0 134 # Scenario make a transfer that total discount < below transfer.feeDiscountMinimumTrackedAmount and next epoch check total discount = 0 135 136 # fee free discount total = 4000 + 2000 + 1000 137 Given the parties have the following transfer fee discounts: 138 | party | asset | available discount | 139 | f0b40ebdc5b92cf2cf82ff5d0c3f94085d23d5ec2d37d0b929e177c6d4d37e4c | ETH | 7000 | 140 # min fee discount = transfer.feeDiscountMinimumTrackedAmount x quamtum = 0.5 x 100 = 50 141 And the following network parameters are set: 142 | name | value | 143 | transfer.feeDiscountMinimumTrackedAmount | 0.5 | 144 And the following assets are updated: 145 | id | decimal places | quantum | 146 | ETH | 0 | 100 | 147 # assert decay is 7000 * 0.9 148 When the network moves ahead "1" epochs 149 Then the parties have the following transfer fee discounts: 150 | party | asset | available discount | 151 | f0b40ebdc5b92cf2cf82ff5d0c3f94085d23d5ec2d37d0b929e177c6d4d37e4c | ETH | 6300 | 152 153 # transfer depletes fees discount total 154 Given the parties submit the following one off transfers: 155 | id | from | from_account_type | to | to_account_type | asset | amount | delivery_time | 156 | 1 | f0b40ebdc5b92cf2cf82ff5d0c3f94085d23d5ec2d37d0b929e177c6d4d37e4c | ACCOUNT_TYPE_GENERAL | a7c4b181ef9bf5e9029a016f854e4ad471208020fd86187d07f0b420004f06a4 | ACCOUNT_TYPE_GENERAL | ETH | 12490 | 2021-08-26T00:00:10Z | 157 When time is updated to "2021-08-26T00:00:10Z" 158 Then the parties have the following transfer fee discounts: 159 | party | asset | available discount | 160 | f0b40ebdc5b92cf2cf82ff5d0c3f94085d23d5ec2d37d0b929e177c6d4d37e4c | ETH | 55 | 161 162 Given the following transfers should happen: 163 | from | to | from account | to account | market id | amount | asset | 164 | f0b40ebdc5b92cf2cf82ff5d0c3f94085d23d5ec2d37d0b929e177c6d4d37e4c | market | ACCOUNT_TYPE_GENERAL | ACCOUNT_TYPE_FEES_INFRASTRUCTURE | | 0 | ETH | 165 When the network moves ahead "1" epochs 166 # fee discount decay = 55 * 0.9 = 49.5 < 50 so it becomes 0 167 Then the parties have the following transfer fee discounts: 168 | party | asset | available discount | 169 | f0b40ebdc5b92cf2cf82ff5d0c3f94085d23d5ec2d37d0b929e177c6d4d37e4c | ETH | 0 | 170 171 @transfer @fee-discount 172 Scenario: 0057-TRAN-027 when a party makes a transfer and f would be the theoretical fee the party should pay then the fee on the transfer that is actually charged is -min(f-c,0). The system subsequently updates c <- max(0,c-f). At the end of epoch, update c <- c x D and c <- c + all_trading_fees_for_trades_involved_in, if c < M x quantum(M is transfer.feeDiscountMinimumTrackedAmount), then set c <- 0 173 # Scenario make a trade that generates discount > transfer.feeDiscountMinimumTrackedAmount and next epoch check total discount is retained 174 175 # fee free discount total = 4000 + 2000 + 1000 176 Given the parties have the following transfer fee discounts: 177 | party | asset | available discount | 178 | f0b40ebdc5b92cf2cf82ff5d0c3f94085d23d5ec2d37d0b929e177c6d4d37e4c | ETH | 7000 | 179 # min fee discount = transfer.feeDiscountMinimumTrackedAmount x quamtum = 0.5 x 100 = 50 180 And the following network parameters are set: 181 | name | value | 182 | transfer.feeDiscountMinimumTrackedAmount | 0.5 | 183 And the following assets are updated: 184 | id | decimal places | quantum | 185 | ETH | 0 | 100 | 186 187 # transfer depletes fees discount total 188 Given the parties submit the following one off transfers: 189 | id | from | from_account_type | to | to_account_type | asset | amount | delivery_time | 190 | 1 | f0b40ebdc5b92cf2cf82ff5d0c3f94085d23d5ec2d37d0b929e177c6d4d37e4c | ACCOUNT_TYPE_GENERAL | a7c4b181ef9bf5e9029a016f854e4ad471208020fd86187d07f0b420004f06a4 | ACCOUNT_TYPE_GENERAL | ETH | 13950 | 2021-08-26T00:00:10Z | 191 When time is updated to "2021-08-26T00:00:10Z" 192 Then the parties have the following transfer fee discounts: 193 | party | asset | available discount | 194 | f0b40ebdc5b92cf2cf82ff5d0c3f94085d23d5ec2d37d0b929e177c6d4d37e4c | ETH | 25 | 195 And the following transfers should happen: 196 | from | to | from account | to account | market id | amount | asset | 197 | f0b40ebdc5b92cf2cf82ff5d0c3f94085d23d5ec2d37d0b929e177c6d4d37e4c | market | ACCOUNT_TYPE_GENERAL | ACCOUNT_TYPE_FEES_INFRASTRUCTURE | | 0 | ETH | 198 199 Given the parties place the following orders: 200 | party | market id | side | volume | price | resulting trades | type | tif | 201 | a7c4b181ef9bf5e9029a016f854e4ad471208020fd86187d07f0b420004f06a4 | ETH/DEC19 | buy | 5 | 1000 | 0 | TYPE_LIMIT | TIF_GTC | 202 | f0b40ebdc5b92cf2cf82ff5d0c3f94085d23d5ec2d37d0b929e177c6d4d37e4c | ETH/DEC19 | sell | 5 | 1000 | 1 | TYPE_LIMIT | TIF_GTC | 203 When the network moves ahead "1" epochs 204 Then the following transfers should happen: 205 | from | to | from account | to account | market id | amount | asset | 206 | f0b40ebdc5b92cf2cf82ff5d0c3f94085d23d5ec2d37d0b929e177c6d4d37e4c | market | ACCOUNT_TYPE_GENERAL | ACCOUNT_TYPE_FEES_MAKER | ETH/DEC19 | 20 | ETH | 207 | f0b40ebdc5b92cf2cf82ff5d0c3f94085d23d5ec2d37d0b929e177c6d4d37e4c | market | ACCOUNT_TYPE_GENERAL | ACCOUNT_TYPE_FEES_INFRASTRUCTURE | | 10 | ETH | 208 | f0b40ebdc5b92cf2cf82ff5d0c3f94085d23d5ec2d37d0b929e177c6d4d37e4c | market | ACCOUNT_TYPE_GENERAL | ACCOUNT_TYPE_FEES_LIQUIDITY | ETH/DEC19 | 5 | ETH | 209 | market | a7c4b181ef9bf5e9029a016f854e4ad471208020fd86187d07f0b420004f06a4 | ACCOUNT_TYPE_FEES_MAKER | ACCOUNT_TYPE_GENERAL | ETH/DEC19 | 20 | ETH | 210 # fee discount previous epoch decayed to 25 * 0.9 = 22.5 + (trade fees - 20 + 10 + 5) = 57.5 > 50 211 # trade at previous epoch generated total fee discount of 16 + 8 + 4 = 28 < 50 so it becomes 0 212 And the parties have the following transfer fee discounts: 213 | party | asset | available discount | 214 | f0b40ebdc5b92cf2cf82ff5d0c3f94085d23d5ec2d37d0b929e177c6d4d37e4c | ETH | 57 | 215 216 @transfer @fee-discount 217 Scenario: 0057-TRAN-027 when a party makes a transfer and f would be the theoretical fee the party should pay then the fee on the transfer that is actually charged is -min(f-c,0). The system subsequently updates c <- max(0,c-f). At the end of epoch, update c <- c x D and c <- c + all_trading_fees_for_trades_involved_in, if c < M x quantum(M is transfer.feeDiscountMinimumTrackedAmount), then set c <- 0 218 # Scenario make a trade that generates discount but the total discount < transfer.feeDiscountMinimumTrackedAmount and next epoch check total discount is 0 219 220 # fee free discount total = 4000 + 2000 + 1000 221 Given the parties have the following transfer fee discounts: 222 | party | asset | available discount | 223 | f0b40ebdc5b92cf2cf82ff5d0c3f94085d23d5ec2d37d0b929e177c6d4d37e4c | ETH | 7000 | 224 # min fee discount = transfer.feeDiscountMinimumTrackedAmount x quamtum = 0.5 x 100 = 50 225 And the following network parameters are set: 226 | name | value | 227 | transfer.feeDiscountMinimumTrackedAmount | 0.5 | 228 And the following assets are updated: 229 | id | decimal places | quantum | 230 | ETH | 0 | 100 | 231 232 # transfer depletes fees discount total 233 Given the parties submit the following one off transfers: 234 | id | from | from_account_type | to | to_account_type | asset | amount | delivery_time | 235 | 1 | f0b40ebdc5b92cf2cf82ff5d0c3f94085d23d5ec2d37d0b929e177c6d4d37e4c | ACCOUNT_TYPE_GENERAL | a7c4b181ef9bf5e9029a016f854e4ad471208020fd86187d07f0b420004f06a4 | ACCOUNT_TYPE_GENERAL | ETH | 13950 | 2021-08-26T00:00:10Z | 236 When time is updated to "2021-08-26T00:00:10Z" 237 Then the parties have the following transfer fee discounts: 238 | party | asset | available discount | 239 | f0b40ebdc5b92cf2cf82ff5d0c3f94085d23d5ec2d37d0b929e177c6d4d37e4c | ETH | 25 | 240 And the following transfers should happen: 241 | from | to | from account | to account | market id | amount | asset | 242 | f0b40ebdc5b92cf2cf82ff5d0c3f94085d23d5ec2d37d0b929e177c6d4d37e4c | market | ACCOUNT_TYPE_GENERAL | ACCOUNT_TYPE_FEES_INFRASTRUCTURE | | 0 | ETH | 243 244 Given the parties place the following orders: 245 | party | market id | side | volume | price | resulting trades | type | tif | 246 | a7c4b181ef9bf5e9029a016f854e4ad471208020fd86187d07f0b420004f06a4 | ETH/DEC19 | buy | 3 | 1000 | 0 | TYPE_LIMIT | TIF_GTC | 247 | f0b40ebdc5b92cf2cf82ff5d0c3f94085d23d5ec2d37d0b929e177c6d4d37e4c | ETH/DEC19 | sell | 3 | 1000 | 1 | TYPE_LIMIT | TIF_GTC | 248 When the network moves ahead "1" epochs 249 Then the following transfers should happen: 250 | from | to | from account | to account | market id | amount | asset | 251 | f0b40ebdc5b92cf2cf82ff5d0c3f94085d23d5ec2d37d0b929e177c6d4d37e4c | market | ACCOUNT_TYPE_GENERAL | ACCOUNT_TYPE_FEES_MAKER | ETH/DEC19 | 12 | ETH | 252 | f0b40ebdc5b92cf2cf82ff5d0c3f94085d23d5ec2d37d0b929e177c6d4d37e4c | market | ACCOUNT_TYPE_GENERAL | ACCOUNT_TYPE_FEES_INFRASTRUCTURE | | 6 | ETH | 253 | f0b40ebdc5b92cf2cf82ff5d0c3f94085d23d5ec2d37d0b929e177c6d4d37e4c | market | ACCOUNT_TYPE_GENERAL | ACCOUNT_TYPE_FEES_LIQUIDITY | ETH/DEC19 | 3 | ETH | 254 | market | a7c4b181ef9bf5e9029a016f854e4ad471208020fd86187d07f0b420004f06a4 | ACCOUNT_TYPE_FEES_MAKER | ACCOUNT_TYPE_GENERAL | ETH/DEC19 | 12 | ETH | 255 # fee discount previous epoch decayed to 25 * 0.9 = 22.5 + (trade fees = 12 + 6 + 3=21) = 43.5 < 50 256 # trade at previous epoch generated total fee discount of 16 + 8 + 4 = 28 < 50 so it becomes 0 257 And the parties have the following transfer fee discounts: 258 | party | asset | available discount | 259 | f0b40ebdc5b92cf2cf82ff5d0c3f94085d23d5ec2d37d0b929e177c6d4d37e4c | ETH | 0 | 260 261 @transfer @fee-discount 262 Scenario: 0057-TRAN-024 when a party received maker fee f in previous epoch, and transfer.feeDiscountDecayFraction = 0.9, then in 3 epochs the fee-free discount amount would be c = 0.9^3 x f, when a party makes a transfer and the theoretical fee the party should pay is f1, and f1 <= 0.729 x f, then no amount is paid for transfer 263 # fee free discount total = maker fees made = 4000 264 # move ahead 3 epochs but check discount at each epoch 265 Given the parties have the following transfer fee discounts: 266 | party | asset | available discount | 267 | a7c4b181ef9bf5e9029a016f854e4ad471208020fd86187d07f0b420004f06a4 | ETH | 4000 | 268 # assert decay is 3240 * 0.9 269 When the network moves ahead "1" epochs 270 Then the parties have the following transfer fee discounts: 271 | party | asset | available discount | 272 | a7c4b181ef9bf5e9029a016f854e4ad471208020fd86187d07f0b420004f06a4 | ETH | 3600 | 273 274 Given the parties have the following transfer fee discounts: 275 | party | asset | available discount | 276 | a7c4b181ef9bf5e9029a016f854e4ad471208020fd86187d07f0b420004f06a4 | ETH | 3600 | 277 # assert decay is 3600 * 0.9 278 When the network moves ahead "1" epochs 279 Then the parties have the following transfer fee discounts: 280 | party | asset | available discount | 281 | a7c4b181ef9bf5e9029a016f854e4ad471208020fd86187d07f0b420004f06a4 | ETH | 3240 | 282 283 Given the parties have the following transfer fee discounts: 284 | party | asset | available discount | 285 | a7c4b181ef9bf5e9029a016f854e4ad471208020fd86187d07f0b420004f06a4 | ETH | 3240 | 286 # assert decay is 3240 * 0.9 287 When the network moves ahead "1" epochs 288 Then the parties have the following transfer fee discounts: 289 | party | asset | available discount | 290 | a7c4b181ef9bf5e9029a016f854e4ad471208020fd86187d07f0b420004f06a4 | ETH | 2916 | 291 292 # transfer depletes fees discount total 293 Given the parties submit the following one off transfers: 294 | id | from | from_account_type | to | to_account_type | asset | amount | delivery_time | 295 | 1 | a7c4b181ef9bf5e9029a016f854e4ad471208020fd86187d07f0b420004f06a4 | ACCOUNT_TYPE_GENERAL | f0b40ebdc5b92cf2cf82ff5d0c3f94085d23d5ec2d37d0b929e177c6d4d37e4c | ACCOUNT_TYPE_GENERAL | ETH | 5832 | 2021-08-26T00:00:10Z | 296 And time is updated to "2021-08-26T00:00:10Z" 297 When the parties have the following transfer fee discounts: 298 | party | asset | available discount | 299 | a7c4b181ef9bf5e9029a016f854e4ad471208020fd86187d07f0b420004f06a4 | ETH | 0 | 300 Then the following transfers should happen: 301 | from | to | from account | to account | market id | amount | asset | 302 | a7c4b181ef9bf5e9029a016f854e4ad471208020fd86187d07f0b420004f06a4 | market | ACCOUNT_TYPE_GENERAL | ACCOUNT_TYPE_FEES_INFRASTRUCTURE | | 0 | ETH | 303 304 # one more transfer that will incur fees 305 Given the parties submit the following one off transfers: 306 | id | from | from_account_type | to | to_account_type | asset | amount | delivery_time | 307 | 1 | a7c4b181ef9bf5e9029a016f854e4ad471208020fd86187d07f0b420004f06a4 | ACCOUNT_TYPE_GENERAL | f0b40ebdc5b92cf2cf82ff5d0c3f94085d23d5ec2d37d0b929e177c6d4d37e4c | ACCOUNT_TYPE_GENERAL | ETH | 10000 | 2021-08-26T00:00:10Z | 308 When the parties have the following transfer fee discounts: 309 | party | asset | available discount | 310 | a7c4b181ef9bf5e9029a016f854e4ad471208020fd86187d07f0b420004f06a4 | ETH | 0 | 311 Then the following transfers should happen: 312 | from | to | from account | to account | market id | amount | asset | 313 | a7c4b181ef9bf5e9029a016f854e4ad471208020fd86187d07f0b420004f06a4 | market | ACCOUNT_TYPE_GENERAL | ACCOUNT_TYPE_FEES_INFRASTRUCTURE | | 5000 | ETH |