Merge branch 'develop' into lp-fee-distribution-bug

vegaprotocol · Mar 20, 2024 · ab6feb4 · ab6feb4
2 parents c12578e + ec96777
commit ab6feb4
Show file tree

Hide file tree

Showing 16 changed files with 430 additions and 77 deletions.
diff --git a/CHANGELOG.md b/CHANGELOG.md
@@ -14,10 +14,18 @@
 
 - [10926](https://github.com/vegaprotocol/vega/issues/10926) - Backport governance proposal to change market name for spots
 - [906](https://github.com/vegaprotocol/core-test-coverage/issues/906) - Add coverage for `0068-MATC-060`
+- [907](https://github.com/vegaprotocol/core-test-coverage/issues/907) - Add coverage for `0068-MATC-061`
+- [908](https://github.com/vegaprotocol/core-test-coverage/issues/908) - Add coverage for `0068-MATC-062`
+- [909](https://github.com/vegaprotocol/core-test-coverage/issues/909) - Add coverage for `0068-MATC-063`
+- [910](https://github.com/vegaprotocol/core-test-coverage/issues/910) - Add coverage for `0068-MATC-064`
+- [911](https://github.com/vegaprotocol/core-test-coverage/issues/911) - Add coverage for `0068-MATC-065`
 
 ### 🐛 Fixes
 
-- [](https://github.com/vegaprotocol/vega/issues/xxxxx)
+- [10946](https://github.com/vegaprotocol/vega/issues/10945) - Save dispatch strategy for recurring governance transfer in the database.
+- [10943](https://github.com/vegaprotocol/vega/issues/10943) - Fix error message format when node vote is sent again.
+- [10928](https://github.com/vegaprotocol/vega/issues/10928) - Fix `collateralIncreaseEstimate` for limit orders in isolated margin mode
+- [10952](https://github.com/vegaprotocol/vega/issues/10952) - Fix bug that caused spot markets to get stuck in opening auction.
 
 ## 0.75.0
 

diff --git a/core/execution/spot/auction.go b/core/execution/spot/auction.go
@@ -88,20 +88,8 @@ func (m *Market) checkAuction(ctx context.Context, now time.Time, idgen common.I
 			return
 		}
 
-		// check that from liquidity point of view we can leave the opening auction
-		_, bestStaticBidVolume, _ := m.getBestStaticBidPriceAndVolume()
-		_, bestStaticAskVolume, _ := m.getBestStaticAskPriceAndVolume()
-		if m.getSuppliedStake().GTE(m.getTargetStake()) && bestStaticBidVolume > 0 && bestStaticAskVolume > 0 {
-			m.as.SetReadyToLeave()
-		}
-
-		if !m.as.CanLeave() {
-			if e := m.as.AuctionExtended(ctx, now); e != nil {
-				m.broker.Send(e)
-			}
-			return
-		}
-		// opening auction requirements satisfied at this point, other requirements still need to be checked downstream though
+		// opening auction period has expired, and we have trades, we should be ready to leave
+		// other requirements still need to be checked downstream though
 		m.as.SetReadyToLeave()
 		m.pMonitor.CheckPrice(ctx, m.as, trades, true, false)
 		if m.as.ExtensionTrigger() == types.AuctionTriggerPrice {

diff --git a/core/governance/market.go b/core/governance/market.go
@@ -671,6 +671,10 @@ func validateRiskParameters(rp interface{}) (types.ProposalError, error) {
 		return validateLogNormalRiskParams(r.LogNormal)
 	case *types.UpdateMarketConfigurationLogNormal:
 		return validateLogNormalRiskParams(r.LogNormal)
+	case *types.NewSpotMarketConfigurationSimple:
+		return types.ProposalErrorUnspecified, nil
+	case *types.UpdateSpotMarketConfigurationSimple:
+		return types.ProposalErrorUnspecified, nil
 	case *types.NewSpotMarketConfigurationLogNormal:
 		return validateLogNormalRiskParams(r.LogNormal)
 	case *types.UpdateSpotMarketConfigurationLogNormal:

diff --git a/core/integration/features/price_monitoring/price-monitoring-lognormal.feature b/core/integration/features/price_monitoring/price-monitoring-lognormal.feature
@@ -385,4 +385,45 @@ Feature: Price monitoring test using forward risk model (bounds for the valid pr
     When time is updated to "2020-10-16T00:12:11Z"
     Then the trading mode should be "TRADING_MODE_CONTINUOUS" for the market "ETH/DEC21"
 
-    And the mark price should be "133000" for the market "ETH/DEC21"
+    And the mark price should be "133000" for the market "ETH/DEC21"
+
+    Scenario: Non-persistent order results in no trades. Persistent order which results in an n-th trade breaching the trigger and causing auction - all previous n-1 trades get executed.
+    Given the parties deposit on asset's general account the following amount:
+      | party  | asset | amount       |
+      | party1 | ETH   | 10000000000  |
+      | party2 | ETH   | 10000000000  |
+      | aux    | ETH   | 100000000000 |
+      | aux2   | ETH   | 100000000000 |
+
+    And the parties place the following orders:
+      | party | market id | side | volume | price  | resulting trades | type       | tif     |
+      | aux   | ETH/DEC21 | buy  | 1      | 1      | 0                | TYPE_LIMIT | TIF_GTC |
+      | aux   | ETH/DEC21 | sell | 1      | 200000 | 0                | TYPE_LIMIT | TIF_GTC |
+      | aux2  | ETH/DEC21 | buy  | 1      | 100000 | 0                | TYPE_LIMIT | TIF_GTC |
+      | aux   | ETH/DEC21 | sell | 1      | 100000 | 0                | TYPE_LIMIT | TIF_GTC |
+    And the opening auction period ends for market "ETH/DEC21"
+    Then the market data for the market "ETH/DEC21" should be:
+      | mark price | trading mode            | horizon | min bound | max bound |
+      | 100000     | TRADING_MODE_CONTINUOUS | 60      | 99461     | 100541    |
+      | 100000     | TRADING_MODE_CONTINUOUS | 120     | 99000     | 101008    |
+
+    When the parties place the following orders with ticks:
+      | party    | market id | side | volume | price  | resulting trades | type       | tif     | error                                                       |
+      | aux      | ETH/DEC21 | sell | 3      | 100540 | 0                | TYPE_LIMIT | TIF_GTC |                                                             |
+      | aux2     | ETH/DEC21 | sell | 2      | 100541 | 0                | TYPE_LIMIT | TIF_GTC |                                                             |
+      | party1   | ETH/DEC21 | sell | 1      | 100542 | 0                | TYPE_LIMIT | TIF_GTC |                                                             |
+      | party2   | ETH/DEC21 | buy  | 10     | 100543 | 0                | TYPE_LIMIT | TIF_IOC | OrderError: non-persistent order trades out of price bounds |
+    Then the market data for the market "ETH/DEC21" should be:
+      | mark price | trading mode            | horizon | min bound | max bound |
+      | 100000     | TRADING_MODE_CONTINUOUS | 60      | 99461     | 100541    |
+      | 100000     | TRADING_MODE_CONTINUOUS | 120     | 99000     | 101008    |
+
+    When the parties place the following orders with ticks:
+      | party    | market id | side | volume | price  | resulting trades | type       | tif     |
+      | party2   | ETH/DEC21 | buy  | 10     | 100543 | 0                | TYPE_LIMIT | TIF_GTC |
+    Then the market data for the market "ETH/DEC21" should be:
+      | mark price | trading mode                    | auction trigger       | horizon | min bound | max bound |
+      | 100000     | TRADING_MODE_MONITORING_AUCTION | AUCTION_TRIGGER_PRICE | 120     | 99000     | 101008    |
+    And the parties should have the following profit and loss:
+      | party  | volume | unrealised pnl | realised pnl |
+      | party2 | 0      | 0              | 0            |
diff --git a/core/integration/features/spot/orders/0011-MARA-continuous.feature b/core/integration/features/spot/orders/0011-MARA-continuous.feature
@@ -72,7 +72,7 @@ Feature: Spot market
       | limits.markets.maxPeggedOrders | 10    |
 
     When the parties place the following orders:
-      | party  | market id | side | volume | price | resulting trades | type       | tif     | reference |
+      | party  | market id | side | volume | price   | resulting trades | type       | tif     | reference |
       | party2 | BTC/ETH   | sell | 5      | 1000000 | 0                | TYPE_LIMIT | TIF_GTC | t2-s-1    |
 
     And the parties place the following pegged orders:
@@ -81,14 +81,37 @@ Feature: Spot market
 
     Then "party5" should have holding account balance of "1" for asset "BTC"
 
+    And the order book should have the following volumes for market "BTC/ETH":
+      | side | price | volume |
+      | sell | 1000  | 0      |
+
+    #0068-MATC-072, Incoming limit GTT orders match if possible, any remaining is placed on the book.
+    When the parties place the following orders:
+      | party  | market id | side | volume | price | resulting trades | type       | tif     | expires in | reference |
+      | party1 | BTC/ETH   | buy  | 1      | 1000  | 0                | TYPE_LIMIT | TIF_GTT | 2          | buy2      |
+      | party5 | BTC/ETH   | sell | 2      | 1000  | 1                | TYPE_LIMIT | TIF_GTT | 2          | sell2     |
+
+    Then the orders should have the following status:
+      | party  | reference | status        |
+      | party1 | buy2      | STATUS_FILLED |
+      | party5 | sell2     | STATUS_ACTIVE |
+    And the order book should have the following volumes for market "BTC/ETH":
+      | side | price | volume |
+      | sell | 1000  | 1      |
+
+    When the network moves ahead "2" blocks
+    Then the orders should have the following status:
+      | party  | reference | status         |
+      | party5 | sell2     | STATUS_EXPIRED |
+
   Scenario: In Spot market, holding in holding account is correctly calculated for all order types in continuous trading pegged GTC. (0011-MARA-026)
     Given the following network parameters are set:
       | name                           | value |
       | limits.markets.maxPeggedOrders | 10    |
 
     When the parties place the following orders:
-      | party  | market id | side | volume | price | resulting trades | type       | tif     | reference |
-      | party2 | BTC/ETH   | sell | 5      | 1000000 | 0              | TYPE_LIMIT | TIF_GTC | t2-s-1    |
+      | party  | market id | side | volume | price   | resulting trades | type       | tif     | reference |
+      | party2 | BTC/ETH   | sell | 5      | 1000000 | 0                | TYPE_LIMIT | TIF_GTC | t2-s-1    |
 
     When the parties place the following pegged orders:
       | party  | market id | side | volume | pegged reference | offset |
@@ -102,11 +125,12 @@ Feature: Spot market
       | limits.markets.maxPeggedOrders | 10    |
 
     When the parties place the following orders:
-      | party  | market id | side | volume | price | resulting trades | type       | tif     | reference |
-      | party2 | BTC/ETH   | sell | 5      | 1000000 | 0              | TYPE_LIMIT | TIF_GFN | t2-s-1    |
+      | party  | market id | side | volume | price   | resulting trades | type       | tif     | reference |
+      | party2 | BTC/ETH   | sell | 5      | 1000000 | 0                | TYPE_LIMIT | TIF_GFN | t2-s-1    |
 
     When the parties place the following pegged orders:
       | party  | market id | side | volume | pegged reference | offset |
       | party5 | BTC/ETH   | sell | 1      | ASK              | 100    |
 
     Then "party5" should have holding account balance of "1" for asset "BTC"
+
diff --git a/core/integration/features/spot/orders/0068-MATC-061.feature b/core/integration/features/spot/orders/0068-MATC-061.feature
@@ -0,0 +1,146 @@
+Feature: Spot market order tests. Covers 0068-MATC-061, 0068-MATC-062, 0068-MATC-063, 0068-MATC-064, 0068-MATC-065.
+
+  Background:
+    Given time is updated to "2024-01-01T00:00:00Z"
+
+    Given the following network parameters are set:
+      | name                                                | value |
+      | network.markPriceUpdateMaximumFrequency             | 0s    |
+      | market.value.windowLength                           | 1h    |
+
+    Given the following assets are registered:
+      | id  | decimal places |
+      | ETH | 2              |
+      | BTC | 2              |
+
+    Given the fees configuration named "fees-config-1":
+      | maker fee | infrastructure fee |
+      | 0.01      | 0.03               |
+    Given the log normal risk model named "lognormal-risk-model-1":
+      | risk aversion | tau  | mu | r   | sigma |
+      | 0.001         | 0.01 | 0  | 0.0 | 1.2   |
+    And the price monitoring named "price-monitoring-1":
+      | horizon | probability | auction extension |
+      | 3600    | 0.999       | 10                |
+
+    And the spot markets:
+      | id      | name    | base asset | quote asset | risk model             | auction duration | fees          | price monitoring   | decimal places | position decimal places | sla params    |
+      | BTC/ETH | BTC/ETH | BTC        | ETH         | lognormal-risk-model-1 | 1                | fees-config-1 | price-monitoring-1 | 2              | 2                       | default-basic |
+
+    # setup accounts
+    Given the parties deposit on asset's general account the following amount:
+      | party  | asset | amount |
+      | party1 | ETH   | 10000  |
+      | party1 | BTC   | 1000   |
+      | party2 | ETH   | 10000  |
+      | party4 | BTC   | 1000   |
+      | party5 | BTC   | 1000   |
+    And the average block duration is "1"
+
+    # Place some orders to get out of auction
+    And the parties place the following orders:
+      | party  | market id | side | volume | price | resulting trades | type       | tif     |
+      | party1 | BTC/ETH   | buy  | 1      | 998   | 0                | TYPE_LIMIT | TIF_GTC |
+      | party1 | BTC/ETH   | buy  | 1      | 1000  | 0                | TYPE_LIMIT | TIF_GTC |
+      | party5 | BTC/ETH   | sell | 1      | 1000  | 0                | TYPE_LIMIT | TIF_GTC |
+      | party5 | BTC/ETH   | sell | 1      | 1050  | 0                | TYPE_LIMIT | TIF_GTC |
+
+    And the opening auction period ends for market "BTC/ETH"
+    When the network moves ahead "1" blocks
+    Then the trading mode should be "TRADING_MODE_CONTINUOUS" for the market "BTC/ETH"
+    And the mark price should be "1000" for the market "BTC/ETH"
+
+  Scenario: 0068-MATC-061: Incoming MARKET orders will be matched against the opposite side of the book.
+
+    # set up the book with some volume the market order will uncross with
+    When the parties place the following orders:
+      | party  | market id | side | volume | price | resulting trades | type       | tif     | reference  |
+      | party1 | BTC/ETH   | buy  | 5      | 1000  | 0                | TYPE_LIMIT | TIF_GTC | p1-ioc-pas |
+    And the parties place the following orders:
+      | party  | market id | side | volume | price | resulting trades | type        | tif     | reference  |
+      | party5 | BTC/ETH   | sell | 2      | 0     | 1                | TYPE_MARKET | TIF_IOC | p5-ioc-agg |
+	Then the following trades should be executed:
+      | buyer  | price | size | seller |
+      | party1 | 1000  | 2    | party5 |
+    And the orders should have the following status:
+      | party  | reference  | status        |
+      | party1 | p1-ioc-pas | STATUS_ACTIVE |
+      | party5 | p5-ioc-agg | STATUS_FILLED |
+
+    When the network moves ahead "1" blocks
+    Then the trading mode should be "TRADING_MODE_CONTINUOUS" for the market "BTC/ETH"
+    And the market data for the market "BTC/ETH" should be:
+      | mark price | trading mode            | horizon | min bound | max bound | target stake | supplied stake | open interest |
+      | 1000       | TRADING_MODE_CONTINUOUS | 3600    | 959       | 1042      | 0            | 0              | 0             |
+
+  Scenario: 0068-MATC-062: If not enough volume is available to fully fill the order, the remaining will be cancelled.
+    # set up the book with some volume the market order will partially uncross with
+    When the parties place the following orders:
+      | party  | market id | side | volume | price | resulting trades | type       | tif     | reference  |
+      | party1 | BTC/ETH   | buy  | 2      | 1000  | 0                | TYPE_LIMIT | TIF_GTC | p1-ioc-pas |
+    And the parties place the following orders:
+      | party  | market id | side | volume | price | resulting trades | type        | tif     | reference  |
+      | party5 | BTC/ETH   | sell | 5      | 0     | 2                | TYPE_MARKET | TIF_IOC | p5-ioc-agg |
+	Then the following trades should be executed:
+      | buyer  | price | size | seller |
+      | party1 | 1000  | 2    | party5 |
+      | party1 | 998   | 1    | party5 |
+    # filled the order of party 1, the remainder of p5's order is marked as partially filled.
+    And the orders should have the following status:
+      | party  | reference  | status                  |
+      | party1 | p1-ioc-pas | STATUS_FILLED           |
+      | party5 | p5-ioc-agg | STATUS_PARTIALLY_FILLED |
+
+    # To ensure the order is cancelled (meaning in a final state) let's ensure we can't amend the order:
+    When the parties amend the following orders:
+      | party  | reference  | tif     | size delta | error                        |
+      | party5 | p5-ioc-agg | TIF_IOC | -1         | OrderError: Invalid Order ID |
+
+    When the network moves ahead "1" blocks
+    Then the trading mode should be "TRADING_MODE_CONTINUOUS" for the market "BTC/ETH"
+    And the market data for the market "BTC/ETH" should be:
+      | mark price | trading mode            | horizon | min bound | max bound | target stake | supplied stake | open interest |
+      | 998        | TRADING_MODE_CONTINUOUS | 3600    | 959       | 1042      | 0            | 0              | 0             |
+
+  Scenario: 0068-MATC-064: If there is no match the order will be cancelled. (0068-MATC-063: Incoming LIMIT orders will be matched against the opposite side of the book)
+    # set up the book with some volume the market order will uncross with
+    When the parties place the following orders:
+      | party  | market id | side | volume | price | resulting trades | type       | tif     | reference  |
+      | party5 | BTC/ETH   | sell | 2      | 1000  | 0                | TYPE_LIMIT | TIF_IOC | p5-ioc-agg |
+    Then the orders should have the following status:
+      | party  | reference  | status         |
+      | party5 | p5-ioc-agg | STATUS_STOPPED |
+
+    When the network moves ahead "1" blocks
+    Then the trading mode should be "TRADING_MODE_CONTINUOUS" for the market "BTC/ETH"
+    And the market data for the market "BTC/ETH" should be:
+      | mark price | trading mode            | horizon | min bound | max bound | target stake | supplied stake | open interest |
+      | 1000       | TRADING_MODE_CONTINUOUS | 3600    | 959       | 1042      | 0            | 0              | 0             |
+
+  Scenario: 0068-MATC-065: If there is a partial match then the remaining will be cancelled. (0068-MATC-063: Incoming LIMIT orders will be matched against the opposite side of the book)
+    # set up the book with some volume the limit order will partially uncross with
+    When the parties place the following orders:
+      | party  | market id | side | volume | price | resulting trades | type       | tif     | reference  |
+      | party1 | BTC/ETH   | buy  | 2      | 1000  | 0                | TYPE_LIMIT | TIF_GTC | p1-ioc-pas |
+    And the parties place the following orders:
+      | party  | market id | side | volume | price | resulting trades | type       | tif     | reference  |
+      | party5 | BTC/ETH   | sell | 5      | 1000  | 1                | TYPE_LIMIT | TIF_IOC | p5-ioc-agg |
+	Then the following trades should be executed:
+      | buyer  | price | size | seller |
+      | party1 | 1000  | 2    | party5 |
+    # filled the order of party 1, the remainder of p5's order is marked as partially filled.
+    And the orders should have the following status:
+      | party  | reference  | status                  |
+      | party1 | p1-ioc-pas | STATUS_FILLED           |
+      | party5 | p5-ioc-agg | STATUS_PARTIALLY_FILLED |
+
+    # To ensure the order is cancelled (meaning in a final state) let's ensure we can't amend the order:
+    When the parties amend the following orders:
+      | party  | reference  | tif     | size delta | error                        |
+      | party5 | p5-ioc-agg | TIF_IOC | -1         | OrderError: Invalid Order ID |
+
+    When the network moves ahead "1" blocks
+    Then the trading mode should be "TRADING_MODE_CONTINUOUS" for the market "BTC/ETH"
+    And the market data for the market "BTC/ETH" should be:
+      | mark price | trading mode            | horizon | min bound | max bound | target stake | supplied stake | open interest |
+      | 1000       | TRADING_MODE_CONTINUOUS | 3600    | 959       | 1042      | 0            | 0              | 0             |