Merge branch 'develop' into cometv1

Author: ze97286

CHANGELOG.md

@@ -14,6 +14,7 @@
 
 - [11209](https://github.com/vegaprotocol/vega/issues/11209) - Publish ongoing games data.
 - [11242](https://github.com/vegaprotocol/vega/issues/11242) - Add configuration to visor to help control binary retries a bit better.
+- [11408](https://github.com/vegaprotocol/vega/issues/11408) - Relax finality check to allow instant deposits over the `Arbitrum` bridge.
 - [11196](https://github.com/vegaprotocol/vega/issues/11196) - Add an active field in the price monitoring bounds payload.
 - [11211](https://github.com/vegaprotocol/vega/issues/11211) - Liquidation engine includes `vAMM` shapes as available volume.
 - [11217](https://github.com/vegaprotocol/vega/issues/11217) - Allow market proposals to override risk factors.
@@ -47,6 +48,7 @@
 - [11368](https://github.com/vegaprotocol/vega/issues/11368) - Add support for update vesting stats in REST API and fix summing the quantum balance for vesting stats.
 - [11380](https://github.com/vegaprotocol/vega/issues/11380) - Handle broken stop orders in prepare proposal. 
 - [11136](https://github.com/vegaprotocol/vega/issues/11136) - Fix premature invocation of post commit hooks in case of fee stats event.
+- [11409](https://github.com/vegaprotocol/vega/issues/11409) - When updating a capped market - copy the cap from the existing market definition. 
 
 ## 0.76.1
 

cmd/vega/commands/node/node.go

@@ -478,11 +478,11 @@ func (n *Command) startBlockchainClients() error {
 
 	n.primaryEthConfirmations = ethclient.NewEthereumConfirmations(n.conf.Ethereum, n.primaryEthClient, nil, ethclient.FinalityStateFinalized)
 
-	// for arbitrum we can use the weaker check for finality and only require that the block is marked as "safe".
-	// This is because "safe" means that the batch has been send to L1 Ethereum and from then on its "final" on
-	// Arbitrum. If the batched-transaction is part of a re-org on Ethereum, it doesn't matter to Vega because core
-	// is only looking at the Arbitrum blocks we don't track the batch, so we don't need to wait for full finality.
-	n.secondaryEthConfirmations = ethclient.NewEthereumConfirmations(n.conf.Ethereum, n.secondaryEthClient, nil, ethclient.FinalityStateSafe)
+	// for arbitrum the finality state of a block is in now way connected to the Arbitrum network reaching consensus so Vega gains nothing
+	// from waiting for safe/finalized. Instead we just wait for the event to be seen in the latest block and rely on the consensus check
+	// Vega performs itself with node-votes. If each validator is running their own Arbitrum node, or is using a node that they need trustworthy
+	// then this is sufficient. A far as is know, block reorgs do not happen on Arbitrum.
+	n.secondaryEthConfirmations = ethclient.NewEthereumConfirmations(n.conf.Ethereum, n.secondaryEthClient, nil, ethclient.FinalityStateLatest)
 
 	return nil
 }

core/client/eth/ethereum_confirmations.go

@@ -109,6 +109,11 @@ func (e *EthereumConfirmations) Check(block uint64) error {
 		return err
 	}
 
+	// if finality state is "latest" we do not need to check as this will already be done by the confirmations count
+	if e.finState == nil {
+		return nil
+	}
+
 	finalized, err := e.finalizedHeight(context.Background())
 	if err != nil {
 		return err

core/execution/amm/pool.go

@@ -54,25 +54,25 @@ func (c *curve) volumeBetweenPrices(sqrt sqrtFn, st, nd *num.Uint) uint64 {
 		return 0
 	}
 
+	stP := impliedPosition(sqrt(st), sqrt(c.high), c.l)
+	ndP := impliedPosition(sqrt(nd), sqrt(c.high), c.l)
+
 	// abs(P(st) - P(nd))
-	volume, _ := num.UintZero().Delta(
-		impliedPosition(sqrt(st), sqrt(c.high), c.l),
-		impliedPosition(sqrt(nd), sqrt(c.high), c.l),
-	)
-	return volume.Uint64()
+	volume := stP.Sub(ndP).Abs()
+	return uint64(volume.IntPart())
 }
 
 // positionAtPrice returns the position of the AMM if its fair-price were the given price. This
 // will be signed for long/short as usual.
 func (c *curve) positionAtPrice(sqrt sqrtFn, price *num.Uint) int64 {
 	pos := impliedPosition(sqrt(price), sqrt(c.high), c.l)
 	if c.isLower {
-		return int64(pos.Uint64())
+		return pos.IntPart()
 	}
 
 	// if we are in the upper curve the position of 0 in "curve-space" is -cu.pv in Vega position
 	// so we need to flip the interval
-	return -c.pv.Sub(pos.ToDecimal()).IntPart()
+	return -c.pv.Sub(pos).IntPart()
 }
 
 type Pool struct {
@@ -494,16 +494,15 @@ func (p *Pool) setCurves(
 // impliedPosition returns the position of the pool if its fair-price were the given price. `l` is
 // the virtual liquidity of the pool, and `sqrtPrice` and `sqrtHigh` are, the square-roots of the
 // price to calculate the position for, and higher boundary of the curve.
-func impliedPosition(sqrtPrice, sqrtHigh num.Decimal, l num.Decimal) *num.Uint {
+func impliedPosition(sqrtPrice, sqrtHigh num.Decimal, l num.Decimal) num.Decimal {
 	// L * (sqrt(high) - sqrt(price))
 	numer := sqrtHigh.Sub(sqrtPrice).Mul(l)
 
 	// sqrt(high) * sqrt(price)
 	denom := sqrtHigh.Mul(sqrtPrice)
 
 	// L * (sqrt(high) - sqrt(price)) / sqrt(high) * sqrt(price)
-	res, _ := num.UintFromDecimal(numer.Div(denom))
-	return res
+	return numer.Div(denom)
 }
 
 // OrderbookShape returns slices of virtual buy and sell orders that the AMM has over a given range

core/execution/amm/pool_test.go

@@ -133,6 +133,52 @@ func testTradeableVolumeInRange(t *testing.T) {
 	}
 }
 
+func TestTradeableVolumeWhenAtBoundary(t *testing.T) {
+	// from ticket 11389 this replicates a scenario found during fuzz testing
+	submit := &types.SubmitAMM{
+		AMMBaseCommand: types.AMMBaseCommand{
+			Party:             vgcrypto.RandomHash(),
+			MarketID:          vgcrypto.RandomHash(),
+			SlippageTolerance: num.DecimalFromFloat(0.1),
+		},
+		CommitmentAmount: num.MustUintFromString("2478383748073213000000", 10),
+		Parameters: &types.ConcentratedLiquidityParameters{
+			Base:                 num.NewUint(676540),
+			LowerBound:           num.NewUint(671272),
+			UpperBound:           nil,
+			LeverageAtLowerBound: ptr.From(num.DecimalFromFloat(39.1988064541227)),
+			LeverageAtUpperBound: nil,
+		},
+	}
+
+	p := newTestPoolWithSubmission(t,
+		num.DecimalFromInt64(1000),
+		submit,
+	)
+	defer p.ctrl.Finish()
+
+	// when position is zero fair-price should be the base
+	ensurePositionN(t, p.pos, 0, num.UintZero(), 3)
+	fp := p.pool.BestPrice(nil)
+	assert.Equal(t, "6765400000000000000000", fp.String())
+
+	fullLong := 12546
+
+	// volume from base -> low is 12546, but in reality it is 12546.4537027400278, but we can only trade int volume.
+	volume := p.pool.TradableVolumeInRange(types.SideSell, num.MustUintFromString("6712720000000000000000", 10), num.MustUintFromString("6765400000000000000000", 10))
+	assert.Equal(t, fullLong, int(volume))
+
+	// now lets pretend the AMM has fully traded out in that direction, best price will be near but not quite the lower bound
+	ensurePositionN(t, p.pos, int64(fullLong), num.UintZero(), 3)
+	fp = p.pool.BestPrice(nil)
+	assert.Equal(t, "6712721893865935337785", fp.String())
+	assert.True(t, fp.GTE(num.MustUintFromString("6712720000000000000000", 10)))
+
+	// now the fair-price is not *quite* on the lower boundary but the volume between it at the lower bound should be 0.
+	volume = p.pool.TradableVolumeInRange(types.SideSell, num.MustUintFromString("6712720000000000000000", 10), fp)
+	assert.Equal(t, 0, int(volume))
+}
+
 func testPoolPositionFactor(t *testing.T) {
 	p := newTestPoolWithPositionFactor(t, num.DecimalFromInt64(1000))
 	defer p.ctrl.Finish()
@@ -806,6 +852,45 @@ func newTestPoolWithOpts(t *testing.T, positionFactor num.Decimal, low, base, hi
 	}
 }
 
+func newTestPoolWithSubmission(t *testing.T, positionFactor num.Decimal, submit *types.SubmitAMM) *tstPool {
+	t.Helper()
+	ctrl := gomock.NewController(t)
+	col := mocks.NewMockCollateral(ctrl)
+	pos := mocks.NewMockPosition(ctrl)
+
+	sqrter := &Sqrter{cache: map[string]num.Decimal{}}
+
+	pool, err := NewPool(
+		vgcrypto.RandomHash(),
+		vgcrypto.RandomHash(),
+		vgcrypto.RandomHash(),
+		submit,
+		sqrter.sqrt,
+		col,
+		pos,
+		&types.RiskFactor{
+			Short: num.DecimalFromFloat(0.009937604878885509),
+			Long:  num.DecimalFromFloat(0.00984363574304481),
+		},
+		&types.ScalingFactors{
+			InitialMargin: num.DecimalFromFloat(1.5), // this is 1/0.8 which is margin_usage_at_bound_above in the note-book
+		},
+		num.DecimalFromFloat(0.001),
+		num.DecimalFromFloat(10000000000000000),
+		positionFactor,
+		num.NewUint(1000),
+	)
+	assert.NoError(t, err)
+
+	return &tstPool{
+		submission: submit,
+		pool:       pool,
+		col:        col,
+		pos:        pos,
+		ctrl:       ctrl,
+	}
+}
+
 type marketPosition struct {
 	size         int64
 	averageEntry *num.Uint

core/governance/engine.go

@@ -1349,6 +1349,7 @@ func (e *Engine) updatedMarketFromProposal(p *proposal) (*types.Market, types.Pr
 				DataSourceSpecForSettlementData:     product.Future.DataSourceSpecForSettlementData,
 				DataSourceSpecForTradingTermination: product.Future.DataSourceSpecForTradingTermination,
 				DataSourceSpecBinding:               product.Future.DataSourceSpecBinding,
+				Cap:                                 existingMarket.GetFuture().Cap(),
 			},
 		}
 	case *types.UpdateInstrumentConfigurationPerps:
@@ -1377,7 +1378,6 @@ func (e *Engine) updatedMarketFromProposal(p *proposal) (*types.Market, types.Pr
 	if newMarket.Changes.LiquidationStrategy == nil {
 		newMarket.Changes.LiquidationStrategy = existingMarket.LiquidationStrategy
 	}
-
 	if perr, err := validateUpdateMarketChange(terms, existingMarket, &enactmentTime{current: p.Terms.EnactmentTimestamp, shouldNotVerify: true}, e.timeService.GetTimeNow(), e.netp); err != nil {
 		return nil, perr, err
 	}

core/integration/features/amm/0042-LIQF-109.feature

@@ -206,6 +206,6 @@ Feature: Test vAMM implied commitment is working as expected
     #virtual stake is 75% * 4669 = 3501
     And the liquidity provider fee shares for the market "ETH/MAR22" should be:
       | party                                                            | equity like share | virtual stake         | average entry valuation |
-      | 137112507e25d3845a56c47db15d8ced0f28daa8498a0fd52648969c4b296aba | 0                 | 3501.0000000000000000 | 23501                   |
+      | 137112507e25d3845a56c47db15d8ced0f28daa8498a0fd52648969c4b296aba | 0                 | 3502.0000000000000000 | 23502                   |
 
 

core/integration/features/amm/0090-VAMM-005.feature

@@ -119,10 +119,10 @@ Feature: Test vAMM submission works as expected (invalid submission)
 
      When the parties submit the following AMM:
        | party | market id | amount | slippage | base | lower bound | lower leverage | proposed fee |
-       | vamm4 | ETH/MAR22 | 100000  | 0.1      | 105  | 99         | 0.1            | 0.01         |
+       | vamm4 | ETH/MAR22 | 100000 | 0.1      | 100  | 99          | 0.1            | 0.01         |
      Then the AMM pool status should be:
        | party | market id | amount | status         | base | lower bound | lower leverage |
-       | vamm4 | ETH/MAR22 | 100000  | STATUS_ACTIVE | 105  | 99          | 0.1            |
+       | vamm4 | ETH/MAR22 | 100000  | STATUS_ACTIVE | 100  | 99          | 0.1            |
 
      When the parties submit the following AMM:
        | party | market id | amount | slippage | base | upper bound | upper leverage | proposed fee |

core/integration/features/amm/0090-VAMM-016.feature

@@ -90,7 +90,7 @@ Feature: vAMM has the same ELS as liquidity provision with the same commitment a
     When the parties submit the following liquidity provision:
       # Using 9788 instead of exactly 10,000 makes things easier because getting exactly 10,000 from an AMM pool as virtual stake can be tricky due to complex math.
       | id   | party | market id | commitment amount | fee   | lp type    |
-      | lp_2 | lp2   | ETH/MAR22 | 9884              | 0.03  | submission |
+      | lp_2 | lp2   | ETH/MAR22 | 9887              | 0.03  | submission |
 
     When the parties submit the following AMM:
       | party | market id | amount | slippage | base | lower bound | upper bound | lower leverage | upper leverage | proposed fee |
@@ -110,8 +110,8 @@ Feature: vAMM has the same ELS as liquidity provision with the same commitment a
     And the current epoch is "2"
     And the liquidity provider fee shares for the market "ETH/MAR22" should be:
       | party                                                            | equity like share  | virtual stake         | average entry valuation |
-      | lp2                                                              | 0.3320343993550121 | 9884.0000000000000000 | 29768                   |
-      | 137112507e25d3845a56c47db15d8ced0f28daa8498a0fd52648969c4b296aba | 0.3320343993550121 | 9884.0000000000000000 | 19884                   |  
+      | lp2                                                              | 0.3320682474642305 | 9887.0000000000000000 | 29774                   |
+      | 137112507e25d3845a56c47db15d8ced0f28daa8498a0fd52648969c4b296aba | 0.3320682474642305 | 9887.0000000000000000 | 19887                   |  
 
   @VAMM
   Scenario: 0090-VAMM-017: A vAMM's virtual ELS should be equal to the ELS of a regular LP with the same committed volume on the book (i.e. if a vAMM has an average volume on each side of the book across the epoch of 10k USDT, their ELS should be equal to that of a regular LP who has a commitment which requires supplying 10k USDT who joined at the same time as them).
@@ -123,7 +123,7 @@ Feature: vAMM has the same ELS as liquidity provision with the same commitment a
     When the parties submit the following liquidity provision:
       # Using 10,093 instead of exactly 10,000 makes things easier because getting exactly 10,000 from an AMM pool as virtual stake can be tricky due to complex math.
       | id   | party | market id | commitment amount | fee   | lp type    |
-      | lp_2 | lp2   | ETH/MAR22 | 9884              | 0.03  | submission |
+      | lp_2 | lp2   | ETH/MAR22 | 9887              | 0.03  | submission |
 
     And the parties place the following orders:
       | party | market id | side | volume | price | resulting trades | type       | tif   |
@@ -148,13 +148,13 @@ Feature: vAMM has the same ELS as liquidity provision with the same commitment a
     And the current epoch is "2"
     And the liquidity provider fee shares for the market "ETH/MAR22" should be:
       | party                                                            | equity like share  | virtual stake         | average entry valuation |
-      | lp2                                                              | 0.3320343993550121 | 9884.0000000000000000 | 29768                   |
-      | 137112507e25d3845a56c47db15d8ced0f28daa8498a0fd52648969c4b296aba | 0.3320343993550121 | 9884.0000000000000000 | 19884                   |
+      | lp2                                                              | 0.3320682474642305 | 9887.0000000000000000 | 29774                   |
+      | 137112507e25d3845a56c47db15d8ced0f28daa8498a0fd52648969c4b296aba | 0.3320682474642305 | 9887.0000000000000000 | 19887                   |
 
   Then the network moves ahead "2" epochs
   And the current epoch is "4"
 
   And the liquidity provider fee shares for the market "ETH/MAR22" should be:
     | party                                                            | equity like share  | virtual stake         | average entry valuation |
-    | lp2                                                              | 0.3320343993550121 | 9884.0000000000000000 | 29768                   |
-    | 137112507e25d3845a56c47db15d8ced0f28daa8498a0fd52648969c4b296aba | 0.3320343993550121 | 9884.0000000000000000 | 19884                   |
+    | lp2                                                              | 0.3320682474642305 | 9887.0000000000000000 | 29774                   |
+    | 137112507e25d3845a56c47db15d8ced0f28daa8498a0fd52648969c4b296aba | 0.3320682474642305 | 9887.0000000000000000 | 19887                   |