code.vegaprotocol.io/vega@v0.79.0/core/integration/features/spot/orders/0014-ORDT-102.feature (about) 1 Feature: Spot market 2 3 Background: 4 Given time is updated to "2024-01-01T00:00:00Z" 5 6 Given the following network parameters are set: 7 | name | value | 8 | network.markPriceUpdateMaximumFrequency | 0s | 9 | market.value.windowLength | 1h | 10 11 Given the following assets are registered: 12 | id | decimal places | 13 | ETH | 2 | 14 | BTC | 2 | 15 16 Given the fees configuration named "fees-config-1": 17 | maker fee | infrastructure fee | 18 | 0.01 | 0.03 | 19 Given the log normal risk model named "lognormal-risk-model-1": 20 | risk aversion | tau | mu | r | sigma | 21 | 0.001 | 0.01 | 0 | 0.0 | 1.2 | 22 And the price monitoring named "price-monitoring-1": 23 | horizon | probability | auction extension | 24 | 360000 | 0.999 | 1 | 25 26 And the spot markets: 27 | id | name | base asset | quote asset | risk model | auction duration | fees | price monitoring | decimal places | position decimal places | sla params | 28 | BTC/ETH | BTC/ETH | BTC | ETH | lognormal-risk-model-1 | 1 | fees-config-1 | price-monitoring-1 | 2 | 2 | default-basic | 29 30 # setup accounts 31 Given the parties deposit on asset's general account the following amount: 32 | party | asset | amount | 33 | party1 | ETH | 10000 | 34 | party2 | ETH | 10000 | 35 | party4 | BTC | 100 | 36 | party5 | BTC | 100 | 37 And the average block duration is "1" 38 39 # Place some orders to get out of auction 40 And the parties place the following orders: 41 | party | market id | side | volume | price | resulting trades | type | tif | 42 | party1 | BTC/ETH | buy | 1 | 1000 | 0 | TYPE_LIMIT | TIF_GFA | 43 | party5 | BTC/ETH | sell | 1 | 1000 | 0 | TYPE_LIMIT | TIF_GTC | 44 45 And the opening auction period ends for market "BTC/ETH" 46 When the network moves ahead "1" blocks 47 Then the trading mode should be "TRADING_MODE_CONTINUOUS" for the market "BTC/ETH" 48 And the mark price should be "1000" for the market "BTC/ETH" 49 50 Scenario: Amending an iceberg order to decrease size will decrease the total and remaining quantities and time priority 51 of the order is not lost (0014-ORDT-102) 52 53 # Set up a price level to have 3 orders with our iceberg in the middle 54 And the parties place the following orders: 55 | party | market id | side | volume | price | resulting trades | type | tif | reference | 56 | party2 | BTC/ETH | buy | 1 | 1000 | 0 | TYPE_LIMIT | TIF_GTC | buy1 | 57 58 When the parties place the following iceberg orders: 59 | party | market id | side | volume | price | resulting trades | type | tif | peak size | minimum visible size | only | reference | 60 | party1 | BTC/ETH | buy | 5 | 1000 | 0 | TYPE_LIMIT | TIF_GTC | 2 | 2 | post | iceberg1 | 61 62 And the parties place the following orders: 63 | party | market id | side | volume | price | resulting trades | type | tif | reference | 64 | party2 | BTC/ETH | buy | 1 | 1000 | 0 | TYPE_LIMIT | TIF_GTC | buy2 | 65 66 # Amend the iceberg to have a smaller size 67 When the parties amend the following orders: 68 | party | reference | price | size delta | tif | 69 | party1 | iceberg1 | 1000 | -3 | TIF_GTC | 70 71 # Now send in a sell order, if the time order is untouched it will match against the first normal order and the iceberg 72 And the parties place the following orders: 73 | party | market id | side | volume | price | resulting trades | type | tif | reference | 74 | party5 | BTC/ETH | sell | 2 | 1000 | 2 | TYPE_LIMIT | TIF_GTC | sell1 | 75 76 Then the orders should have the following states: 77 | party | market id | side | price | remaining | volume | reference | status | 78 | party2 | BTC/ETH | buy | 1000 | 0 | 1 | buy1 | STATUS_FILLED | 79 | party1 | BTC/ETH | buy | 1000 | 1 | 2 | iceberg1 | STATUS_ACTIVE | 80 | party2 | BTC/ETH | buy | 1000 | 1 | 1 | buy2 | STATUS_ACTIVE | 81 | party5 | BTC/ETH | sell | 1000 | 0 | 2 | sell1 | STATUS_FILLED |