diff --git a/core/execution/amm/engine.go b/core/execution/amm/engine.go
index ff162d55ec4..7d5bf748ce4 100644
--- a/core/execution/amm/engine.go
+++ b/core/execution/amm/engine.go
@@ -656,7 +656,7 @@ func (e *Engine) SubmitAMM(
 
 		return err
 	}
-	pool := NewPool(
+	pool, err := NewPool(
 		poolID,
 		subAccount,
 		e.market.GetSettlementAsset(),
@@ -670,6 +670,17 @@ func (e *Engine) SubmitAMM(
 		e.priceFactor,
 		e.positionFactor,
 	)
+	if err != nil {
+		e.broker.Send(
+			events.NewAMMPoolEvent(
+				ctx, submit.Party, e.market.GetID(), subAccount, poolID,
+				submit.CommitmentAmount, submit.Parameters,
+				types.AMMPoolStatusRejected, types.AMMPoolStatusReasonCommitmentTooLow, // TODO Karel - check if this error is ok to return
+			),
+		)
+
+		return err
+	}
 
 	if targetPrice != nil {
 		if err := e.rebasePool(ctx, pool, targetPrice, submit.SlippageTolerance, idgen); err != nil {
@@ -720,7 +731,11 @@ func (e *Engine) AmendAMM(
 
 	oldCommitment := pool.Commitment.Clone()
 	fairPrice := pool.BestPrice(nil)
-	oldParams := pool.Update(amend, e.risk.GetRiskFactors(), e.risk.GetScalingFactors(), e.risk.GetSlippage())
+	oldParams, err := pool.Update(amend, e.risk.GetRiskFactors(), e.risk.GetScalingFactors(), e.risk.GetSlippage())
+	if err != nil {
+		return err
+	}
+
 	if err := e.rebasePool(ctx, pool, fairPrice, amend.SlippageTolerance, idgeneration.New(deterministicID)); err != nil {
 		// couldn't rebase the pool back to its original fair price so the amend is rejected
 		if err := e.updateSubAccountBalance(ctx, amend.Party, pool.SubAccount, oldCommitment); err != nil {
@@ -729,7 +744,9 @@ func (e *Engine) AmendAMM(
 		// restore updated parameters
 		pool.Parameters = oldParams
 		// restore curves
-		pool.setCurves(e.risk.GetRiskFactors(), e.risk.GetScalingFactors(), e.risk.GetSlippage())
+		if err := pool.setCurves(e.risk.GetRiskFactors(), e.risk.GetScalingFactors(), e.risk.GetSlippage()); err != nil {
+			e.log.Panic("could not restore curves after failed rebase", logging.Error(err))
+		}
 
 		return err
 	}
diff --git a/core/execution/amm/pool.go b/core/execution/amm/pool.go
index 9c821efbb74..301b6f87ad9 100644
--- a/core/execution/amm/pool.go
+++ b/core/execution/amm/pool.go
@@ -108,7 +108,7 @@ func NewPool(
 	linearSlippage num.Decimal,
 	priceFactor num.Decimal,
 	positionFactor num.Decimal,
-) *Pool {
+) (*Pool, error) {
 	oneTick, _ := num.UintFromDecimal(num.DecimalOne().Mul(priceFactor))
 	pool := &Pool{
 		ID:             id,
@@ -127,8 +127,11 @@ func NewPool(
 		oneTick:        oneTick,
 		status:         types.AMMPoolStatusActive,
 	}
-	pool.setCurves(rf, sf, linearSlippage)
-	return pool
+	err := pool.setCurves(rf, sf, linearSlippage)
+	if err != nil {
+		return nil, err
+	}
+	return pool, nil
 }
 
 func NewPoolFromProto(
@@ -267,7 +270,7 @@ func (p *Pool) Update(
 	rf *types.RiskFactor,
 	sf *types.ScalingFactors,
 	linearSlippage num.Decimal,
-) *types.ConcentratedLiquidityParameters {
+) (*types.ConcentratedLiquidityParameters, error) {
 	if amend.CommitmentAmount != nil {
 		p.Commitment = amend.CommitmentAmount
 	}
@@ -276,8 +279,10 @@ func (p *Pool) Update(
 	}
 	oldParams := p.Parameters.Clone()
 	p.Parameters.ApplyUpdate(amend.Parameters)
-	p.setCurves(rf, sf, linearSlippage)
-	return oldParams
+	if err := p.setCurves(rf, sf, linearSlippage); err != nil {
+		return oldParams, err
+	}
+	return oldParams, nil
 }
 
 // emptyCurve creates the curve details that represent no liquidity.
@@ -375,7 +380,7 @@ func (p *Pool) setCurves(
 	rfs *types.RiskFactor,
 	sfs *types.ScalingFactors,
 	linearSlippage num.Decimal,
-) {
+) error {
 	// convert the bounds into asset precision
 	base, _ := num.UintFromDecimal(p.Parameters.Base.ToDecimal().Mul(p.priceFactor))
 	p.lower = emptyCurve(base)
@@ -395,6 +400,12 @@ func (p *Pool) setCurves(
 			p.positionFactor,
 			true,
 		)
+
+		highPriceMinusOne := num.UintZero().Sub(p.lower.high, p.oneTick)
+		// verify that the lower curve maintains sufficient volume from highPrice - 1 to the end of the curve.
+		if p.lower.volumeBetweenPrices(p.sqrt, highPriceMinusOne, p.lower.high) < 1 {
+			return fmt.Errorf("insufficient volume in the lower curve from high price - 1 to the end")
+		}
 	}
 
 	if p.Parameters.UpperBound != nil {
@@ -411,7 +422,15 @@ func (p *Pool) setCurves(
 			p.positionFactor,
 			false,
 		)
+
+		highPriceMinusOne := num.UintZero().Sub(p.upper.high, p.oneTick)
+		// verify that the upper curve maintains sufficient volume from highPrice - 1 to the end of the curve.
+		if p.upper.volumeBetweenPrices(p.sqrt, highPriceMinusOne, p.upper.high) < 1 {
+			return fmt.Errorf("insufficient volume in the lower curve from high price - 1 to the end")
+		}
 	}
+
+	return nil
 }
 
 // impliedPosition returns the position of the pool if its fair-price were the given price. `l` is
diff --git a/core/execution/amm/pool_test.go b/core/execution/amm/pool_test.go
index 52d29038da9..108a269d724 100644
--- a/core/execution/amm/pool_test.go
+++ b/core/execution/amm/pool_test.go
@@ -34,6 +34,7 @@ func TestAMMPool(t *testing.T) {
 	t.Run("test best price", testBestPrice)
 	t.Run("test pool logic with position factor", testPoolPositionFactor)
 	t.Run("test one sided pool", testOneSidedPool)
+	t.Run("test near zero volume curve triggers and error", testNearZeroCurveErrors)
 }
 
 func testTradeableVolumeInRange(t *testing.T) {
@@ -212,6 +213,88 @@ func testOneSidedPool(t *testing.T) {
 	assert.Panics(t, func() { p.pool.BestPrice(nil) })
 }
 
+func testNearZeroCurveErrors(t *testing.T) {
+	baseCmd := types.AMMBaseCommand{
+		Party:             vgcrypto.RandomHash(),
+		MarketID:          vgcrypto.RandomHash(),
+		SlippageTolerance: num.DecimalFromFloat(0.1),
+	}
+
+	submit := &types.SubmitAMM{
+		AMMBaseCommand:   baseCmd,
+		CommitmentAmount: num.NewUint(1000),
+		Parameters: &types.ConcentratedLiquidityParameters{
+			Base:                 num.NewUint(1900),
+			LowerBound:           num.NewUint(1800),
+			UpperBound:           num.NewUint(2000),
+			LeverageAtLowerBound: ptr.From(num.DecimalFromFloat(50)),
+			LeverageAtUpperBound: ptr.From(num.DecimalFromFloat(50)),
+		},
+	}
+
+	// test that creating a pool with a near zero volume curve will error
+	pool, err := newBasicPoolWithSubmit(t, submit)
+	assert.Nil(t, pool)
+	assert.ErrorContains(t, err, "insufficient volume in the lower curve from high price - 1 to the end")
+
+	// test that a pool with higher commitment amount will not error
+	submit.CommitmentAmount = num.NewUint(100000)
+	pool, err = newBasicPoolWithSubmit(t, submit)
+	assert.NotNil(t, pool)
+	assert.NoError(t, err)
+
+	// test that amending a pool to a near zero volume curve will error
+	amend := &types.AmendAMM{
+		AMMBaseCommand:   baseCmd,
+		CommitmentAmount: num.NewUint(100),
+	}
+
+	_, err = pool.Update(
+		amend,
+		&types.RiskFactor{Short: num.DecimalFromFloat(0.02), Long: num.DecimalFromFloat(0.02)},
+		&types.ScalingFactors{InitialMargin: num.DecimalFromFloat(1.25)},
+		num.DecimalZero(),
+	)
+	assert.ErrorContains(t, err, "insufficient volume in the lower curve from high price - 1 to the end")
+
+	amend.CommitmentAmount = num.NewUint(1000000)
+	_, err = pool.Update(
+		amend,
+		&types.RiskFactor{Short: num.DecimalFromFloat(0.02), Long: num.DecimalFromFloat(0.02)},
+		&types.ScalingFactors{InitialMargin: num.DecimalFromFloat(1.25)},
+		num.DecimalZero(),
+	)
+	assert.NoError(t, err)
+}
+
+func newBasicPoolWithSubmit(t *testing.T, submit *types.SubmitAMM) (*Pool, error) {
+	ctrl := gomock.NewController(t)
+	col := mocks.NewMockCollateral(ctrl)
+	pos := mocks.NewMockPosition(ctrl)
+
+	sqrter := &Sqrter{cache: map[string]num.Decimal{}}
+
+	return NewPool(
+		vgcrypto.RandomHash(),
+		vgcrypto.RandomHash(),
+		vgcrypto.RandomHash(),
+		submit,
+		sqrter.sqrt,
+		col,
+		pos,
+		&types.RiskFactor{
+			Short: num.DecimalFromFloat(0.02),
+			Long:  num.DecimalFromFloat(0.02),
+		},
+		&types.ScalingFactors{
+			InitialMargin: num.DecimalFromFloat(1.25), // this is 1/0.8 which is margin_usage_at_bound_above in the note-book
+		},
+		num.DecimalZero(),
+		num.DecimalOne(),
+		num.DecimalOne(),
+	)
+}
+
 func ensurePositionN(t *testing.T, p *mocks.MockPosition, pos int64, averageEntry *num.Uint, times int) {
 	t.Helper()
 
@@ -346,7 +429,7 @@ func newTestPoolWithOpts(t *testing.T, positionFactor num.Decimal, low, base, hi
 		},
 	}
 
-	pool := NewPool(
+	pool, err := NewPool(
 		vgcrypto.RandomHash(),
 		vgcrypto.RandomHash(),
 		vgcrypto.RandomHash(),
@@ -365,6 +448,7 @@ func newTestPoolWithOpts(t *testing.T, positionFactor num.Decimal, low, base, hi
 		num.DecimalOne(),
 		positionFactor,
 	)
+	assert.NoError(t, err)
 
 	return &tstPool{
 		pool: pool,
diff --git a/core/integration/features/amm/0012-POSR-032.feature b/core/integration/features/amm/0012-POSR-032.feature
index 2f8d878ee10..735166a586b 100644
--- a/core/integration/features/amm/0012-POSR-032.feature
+++ b/core/integration/features/amm/0012-POSR-032.feature
@@ -71,7 +71,7 @@ Feature: A network disposal order which crosses with volume implied by an vAMM s
       | party4 | USD   | 1000000 |
       | party5 | USD   | 1000000 |
       | partyX | USD   | 100     |
-      | vamm1  | USD   | 10000   |
+      | vamm1  | USD   | 100000  |
 
     When the parties submit the following liquidity provision:
       | id   | party | market id | commitment amount | fee   | lp type    |
@@ -110,18 +110,18 @@ Feature: A network disposal order which crosses with volume implied by an vAMM s
       | mark price | trading mode            | target stake | supplied stake | open interest | ref price | mid price | static mid price |
       | 100        | TRADING_MODE_CONTINUOUS | 79           | 1000           | 2             | 100       | 100       | 100              |
     When the parties submit the following AMM:
-      | party | market id | amount | slippage | base | lower bound | upper bound | lower leverage | upper leverage | proposed fee |
-      | vamm1 | ETH/MAR22 | 10000  | 0.1      | 100  | 85          | 150         | 4              | 4              | 0.01         |
+      | party | market id | amount  | slippage | base | lower bound | upper bound | lower leverage | upper leverage | proposed fee |
+      | vamm1 | ETH/MAR22 | 100000  | 0.1      | 100  | 85          | 150         | 4              | 4              | 0.01         |
     Then the AMM pool status should be:
-      | party | market id | amount | status        | base | lower bound | upper bound | lower leverage | upper leverage |
-      | vamm1 | ETH/MAR22 | 10000  | STATUS_ACTIVE | 100  | 85          | 150         | 4              | 4              |
+      | party | market id | amount  | status        | base | lower bound | upper bound | lower leverage | upper leverage |
+      | vamm1 | ETH/MAR22 | 100000  | STATUS_ACTIVE | 100  | 85          | 150         | 4              | 4              |
 
     And set the following AMM sub account aliases:
       | party | market id | alias    |
       | vamm1 | ETH/MAR22 | vamm1-id |
     And the following transfers should happen:
       | from  | from account         | to       | to account           | market id | amount  | asset | is amm | type                             |
-      | vamm1 | ACCOUNT_TYPE_GENERAL | vamm1-id | ACCOUNT_TYPE_GENERAL |           | 10000   | USD   | true   | TRANSFER_TYPE_AMM_SUBACCOUNT_LOW |
+      | vamm1 | ACCOUNT_TYPE_GENERAL | vamm1-id | ACCOUNT_TYPE_GENERAL |           | 100000  | USD   | true   | TRANSFER_TYPE_AMM_SUBACCOUNT_LOW |
 
   @VAMM
   Scenario: the distressed party uncrosses with the vAMM orders
diff --git a/core/integration/features/amm/0090-VAMM-001.feature b/core/integration/features/amm/0090-VAMM-001.feature
index 9c8ab246be4..003cce0e426 100644
--- a/core/integration/features/amm/0090-VAMM-001.feature
+++ b/core/integration/features/amm/0090-VAMM-001.feature
@@ -61,7 +61,7 @@ Feature: Test vAMM submission works as expected
       | party1 | USD   | 100000 |
       | party2 | USD   | 100000 |
       | party3 | USD   | 100000 |
-      | vamm1  | USD   | 1000   |
+      | vamm1  | USD   | 100000 |
 
     When the parties submit the following liquidity provision:
       | id   | party | market id | commitment amount | fee   | lp type    |
@@ -90,14 +90,14 @@ Feature: Test vAMM submission works as expected
       | 100        | TRADING_MODE_CONTINUOUS | 3600    | 94        | 106       | 39           | 1000           | 1             | 100       | 100       | 100              |
     When the parties submit the following AMM:
       | party | market id | amount | slippage | base | lower bound | upper bound | lower leverage | upper leverage | proposed fee |
-      | vamm1 | ETH/MAR22 | 1000   | 0.1      | 100  | 85          | 150         | 0.25               | 0.25               | 0.01         |
+      | vamm1 | ETH/MAR22 | 100000  | 0.1      | 100  | 85          | 150         | 0.25               | 0.25               | 0.01         |
     Then the AMM pool status should be:
       | party | market id | amount | status        | base | lower bound | upper bound | lower leverage | upper leverage |
-      | vamm1 | ETH/MAR22 | 1000   | STATUS_ACTIVE | 100  | 85          | 150         | 0.25               | 0.25               |
+      | vamm1 | ETH/MAR22 | 100000 | STATUS_ACTIVE | 100  | 85          | 150         | 0.25               | 0.25               |
 
     And set the following AMM sub account aliases:
       | party | market id | alias     |
       | vamm1 | ETH/MAR22 | vamm1-acc |
     And the following transfers should happen:
       | from  | from account         | to        | to account           | market id | amount | asset | is amm | type                             |
-      | vamm1 | ACCOUNT_TYPE_GENERAL | vamm1-acc | ACCOUNT_TYPE_GENERAL |           | 1000   | USD   | true   | TRANSFER_TYPE_AMM_SUBACCOUNT_LOW |
+      | vamm1 | ACCOUNT_TYPE_GENERAL | vamm1-acc | ACCOUNT_TYPE_GENERAL |           | 100000 | USD   | true   | TRANSFER_TYPE_AMM_SUBACCOUNT_LOW |
diff --git a/core/integration/features/amm/0090-VAMM-002.feature b/core/integration/features/amm/0090-VAMM-002.feature
index ea7f29278cd..16acbaa9a16 100644
--- a/core/integration/features/amm/0090-VAMM-002.feature
+++ b/core/integration/features/amm/0090-VAMM-002.feature
@@ -61,7 +61,7 @@ Feature: Test vAMM submission works as expected
       | party1 | USD   | 100000 |
       | party2 | USD   | 100000 |
       | party3 | USD   | 100000 |
-      | vamm1  | USD   | 1000   |
+      | vamm1  | USD   | 100000 |
 
     When the parties submit the following liquidity provision:
       | id   | party | market id | commitment amount | fee   | lp type    |
@@ -90,15 +90,15 @@ Feature: Test vAMM submission works as expected
       | 100        | TRADING_MODE_CONTINUOUS | 3600    | 94        | 106       | 39           | 1000           | 1             | 100       | 100       | 100              |
     When the parties submit the following AMM:
       | party | market id | amount | slippage | base | lower bound | lower leverage | proposed fee |
-      | vamm1 | ETH/MAR22 | 1000   | 0.1      | 100  | 85          | 0.25               | 0.01         |
+      | vamm1 | ETH/MAR22 | 100000 | 0.1      | 100  | 85          | 0.25               | 0.01         |
     Then the AMM pool status should be:
       | party | market id | amount | status        | base | lower bound | lower leverage |
-      | vamm1 | ETH/MAR22 | 1000   | STATUS_ACTIVE | 100  | 85          | 0.25               |
+      | vamm1 | ETH/MAR22 | 100000 | STATUS_ACTIVE | 100  | 85          | 0.25               |
 
     And set the following AMM sub account aliases:
       | party | market id | alias     |
       | vamm1 | ETH/MAR22 | vamm1-acc |
     And the following transfers should happen:
       | from  | from account         | to        | to account           | market id | amount | asset | is amm | type                             |
-      | vamm1 | ACCOUNT_TYPE_GENERAL | vamm1-acc | ACCOUNT_TYPE_GENERAL |           | 1000   | USD   | true   | TRANSFER_TYPE_AMM_SUBACCOUNT_LOW |
+      | vamm1 | ACCOUNT_TYPE_GENERAL | vamm1-acc | ACCOUNT_TYPE_GENERAL |           | 100000 | USD   | true   | TRANSFER_TYPE_AMM_SUBACCOUNT_LOW |
 
diff --git a/core/integration/features/amm/0090-VAMM-003.feature b/core/integration/features/amm/0090-VAMM-003.feature
index c9295979a5c..62e1ca5da1a 100644
--- a/core/integration/features/amm/0090-VAMM-003.feature
+++ b/core/integration/features/amm/0090-VAMM-003.feature
@@ -61,7 +61,7 @@ Feature: Test vAMM submission works as expected
       | party1 | USD   | 100000 |
       | party2 | USD   | 100000 |
       | party3 | USD   | 100000 |
-      | vamm1  | USD   | 1000   |
+      | vamm1  | USD   | 100000 |
 
     When the parties submit the following liquidity provision:
       | id   | party | market id | commitment amount | fee   | lp type    |
@@ -90,15 +90,15 @@ Feature: Test vAMM submission works as expected
       | 100        | TRADING_MODE_CONTINUOUS | 3600    | 94        | 106       | 39           | 1000           | 1             | 100       | 100       | 100              |
     When the parties submit the following AMM:
       | party | market id | amount | slippage | base | upper bound | upper leverage | proposed fee |
-      | vamm1 | ETH/MAR22 | 1000   | 0.1      | 100  | 150         | 0.25               | 0.01         |
+      | vamm1 | ETH/MAR22 | 100000 | 0.1      | 100  | 150         | 0.25               | 0.01         |
     Then the AMM pool status should be:
       | party | market id | amount | status        | base | upper bound | upper leverage |
-      | vamm1 | ETH/MAR22 | 1000   | STATUS_ACTIVE | 100  | 150         | 0.25               |
+      | vamm1 | ETH/MAR22 | 100000 | STATUS_ACTIVE | 100  | 150         | 0.25               |
 
     And set the following AMM sub account aliases:
       | party | market id | alias     |
       | vamm1 | ETH/MAR22 | vamm1-acc |
     And the following transfers should happen:
       | from  | from account         | to        | to account           | market id | amount | asset | is amm | type                             |
-      | vamm1 | ACCOUNT_TYPE_GENERAL | vamm1-acc | ACCOUNT_TYPE_GENERAL |           | 1000   | USD   | true   | TRANSFER_TYPE_AMM_SUBACCOUNT_LOW |
+      | vamm1 | ACCOUNT_TYPE_GENERAL | vamm1-acc | ACCOUNT_TYPE_GENERAL |           | 100000 | USD   | true   | TRANSFER_TYPE_AMM_SUBACCOUNT_LOW |
 
diff --git a/core/integration/features/amm/0090-VAMM-005.feature b/core/integration/features/amm/0090-VAMM-005.feature
index 3d61e227be0..4409cf5d661 100644
--- a/core/integration/features/amm/0090-VAMM-005.feature
+++ b/core/integration/features/amm/0090-VAMM-005.feature
@@ -51,114 +51,114 @@ Feature: Test vAMM submission works as expected (invalid submission)
       | 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 |
       | ETH/MAR22 | USD        | USD   | lqm-params           | log-normal-risk-model | margin-calculator-1 | 2                | fees-config-1 | price-monitoring | default-eth-for-future | 1e0                    | 0                         | SLA-22     |
 
-  @VAMM
-  Scenario: 0090-VAMM-005:  When market.amm.minCommitmentQuantum is 1000, mid price of the market 100, a user with 1000 USDT is able to create a vAMM with commitment 100, and any other combination of settings.
-    Given the parties deposit on asset's general account the following amount:
-      | party  | asset | amount |
-      | lp1    | USD   | 100000 |
-      | lp2    | USD   | 100000 |
-      | lp3    | USD   | 100000 |
-      | party1 | USD   | 100000 |
-      | party2 | USD   | 100000 |
-      | party3 | USD   | 100000 |
-      | vamm1  | USD   | 1000   |
-      | vamm2  | USD   | 1000   |
-      | vamm3  | USD   | 1000   |
-      | vamm4  | USD   | 1000   |
-      | vamm5  | USD   | 1000   |
-      | vamm6  | USD   | 1000   |
-      | vamm7  | USD   | 1000   |
-
-    When the parties submit the following liquidity provision:
-      | id   | party | market id | commitment amount | fee   | lp type    |
-      | lp_1 | lp1   | ETH/MAR22 | 600               | 0.02  | submission |
-      | lp_2 | lp2   | ETH/MAR22 | 400               | 0.015 | submission |
-    Then the network moves ahead "4" blocks
-    And the current epoch is "0"
-
-    And the parties place the following orders:
-      | party  | market id | side | volume | price | resulting trades | type       | tif     | reference |
-      | party3 | ETH/MAR22 | buy  | 10     | 85    | 0                | TYPE_LIMIT | TIF_GTC |           |
-      | party1 | ETH/MAR22 | buy  | 10     | 90    | 0                | TYPE_LIMIT | TIF_GTC |           |
-      | party1 | ETH/MAR22 | buy  | 1      | 100   | 0                | TYPE_LIMIT | TIF_GTC |           |
-      | party2 | ETH/MAR22 | sell | 10     | 110   | 0                | TYPE_LIMIT | TIF_GTC |           |
-      | party2 | ETH/MAR22 | sell | 1      | 100   | 0                | TYPE_LIMIT | TIF_GTC |           |
-      | party3 | ETH/MAR22 | sell | 1      | 120   | 0                | TYPE_LIMIT | TIF_GTC |           |
-      | lp1    | ETH/MAR22 | buy  | 10     | 95    | 0                | TYPE_LIMIT | TIF_GTC | lp1-b     |
-      | lp1    | ETH/MAR22 | sell | 10     | 105   | 0                | TYPE_LIMIT | TIF_GTC | lp1-s     |
-    When the opening auction period ends for market "ETH/MAR22"
-    Then the following trades should be executed:
-      | buyer  | price | size | seller |
-      | party1 | 100   | 1    | party2 |
-
-    And the market data for the market "ETH/MAR22" should be:
-      | mark price | trading mode            | horizon | min bound | max bound | target stake | supplied stake | open interest | ref price | mid price | static mid price |
-      | 100        | TRADING_MODE_CONTINUOUS | 3600    | 94        | 106       | 39           | 1000           | 1             | 100       | 100       | 100              |
-
-    When the parties submit the following AMM:
-      | party | market id | amount | slippage | base | lower bound | upper bound | lower leverage | upper leverage | proposed fee |
-      | vamm1 | ETH/MAR22 | 1000   | 0.1      | 100  | 85          | 150         | 0.25               | 0.25               | 0.01         |
-    Then the AMM pool status should be:
-      | party | market id | amount | status        | base | lower bound | lower leverage | upper bound | upper leverage |
-      | vamm1 | ETH/MAR22 | 1000   | STATUS_ACTIVE | 100  | 85          | 0.25               | 150         | 0.25               |
-
-    When the parties submit the following AMM:
-      | party | market id | amount | slippage | base | lower bound | lower leverage | error                        | proposed fee |
-      | vamm2 | ETH/MAR22 | 1000   | 0.1      | 90   | 85          | 0.25               | rebase target outside bounds | 0.01         |
-    # can't rebase because the target is 100 and thats outside of its bounds given there is no upper
-    Then the AMM pool status should be:
-      | party | market id | amount | status          | base | lower bound | lower leverage | reason                      |
-      | vamm2 | ETH/MAR22 | 1000   | STATUS_REJECTED | 90  | 85          | 0.25                | STATUS_REASON_CANNOT_REBASE |
-
-    When the parties submit the following AMM:
-      | party | market id | amount | slippage | base | upper bound | upper leverage | error                        | proposed fee |
-      | vamm3 | ETH/MAR22 | 1000   | 0.1      | 110  | 150         | 0.25               | rebase target outside bounds | 0.01         |
-    Then the AMM pool status should be:
-      | party | market id | amount | status          | base | upper bound | upper leverage | reason                      |
-      | vamm3 | ETH/MAR22 | 1000   | STATUS_REJECTED | 110  | 150         | 0.25               | STATUS_REASON_CANNOT_REBASE |
-
-    When the parties submit the following AMM:
-      | party | market id | amount | slippage | base | lower bound | lower leverage | proposed fee |
-      | vamm4 | ETH/MAR22 | 1000   | 0.1      | 105  | 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 | 1000   | STATUS_ACTIVE | 105  | 99          | 0.1                |
-
-    When the parties submit the following AMM:
-      | party | market id | amount | slippage | base | upper bound | upper leverage | proposed fee |
-      | vamm5 | ETH/MAR22 | 1000   | 0.1      | 99   | 101         | 0.02               |  0.01        |
-    Then the AMM pool status should be:
-      | party | market id | amount | status          | base | upper bound | upper leverage |
-      | vamm5 | ETH/MAR22 | 1000   | STATUS_ACTIVE   | 99  | 101          | 0.02               |
-
-    When the parties submit the following AMM:
-      | party | market id | amount | slippage | base | lower bound | upper bound | lower leverage | upper leverage | proposed fee |
-      | vamm6 | ETH/MAR22 | 1000   | 0.001    | 101  | 95          | 105         | 0.01               | 0.01               | 0.01         |
-    Then the AMM pool status should be:
-      | party | market id | amount | status        | base | lower bound | lower leverage | upper bound | upper leverage |
-      | vamm6 | ETH/MAR22 | 1000   | STATUS_ACTIVE | 101  | 95          | 0.01               | 105         | 0.01               |
-
-    When the parties submit the following AMM:
-      | party | market id | amount | slippage | base | lower bound | lower leverage | proposed fee |
-      | vamm7 | ETH/MAR22 | 1000   | 0.01     | 110  | 99          | 0.1                | 0.01         |
-    Then the AMM pool status should be:
-      | party | market id | amount | status          | base | lower bound | lower leverage | 
-      | vamm7 | ETH/MAR22 | 1000   | STATUS_ACTIVE   | 110  | 99          | 0.1                | 
-
-    And set the following AMM sub account aliases:
-      | party | market id | alias     |
-      | vamm1 | ETH/MAR22 | vamm1-acc |
-      | vamm2 | ETH/MAR22 | vamm2-acc |
-      | vamm3 | ETH/MAR22 | vamm3-acc |
-      | vamm4 | ETH/MAR22 | vamm4-acc |
-      | vamm5 | ETH/MAR22 | vamm5-acc |
-      | vamm6 | ETH/MAR22 | vamm6-acc |
-    And the following transfers should happen:
-      | from  | from account         | to        | to account           | market id | amount | asset | is amm | type                             |
-      | vamm1 | ACCOUNT_TYPE_GENERAL | vamm1-acc | ACCOUNT_TYPE_GENERAL |           | 1000   | USD   | true   | TRANSFER_TYPE_AMM_SUBACCOUNT_LOW |
-      | vamm2 | ACCOUNT_TYPE_GENERAL | vamm2-acc | ACCOUNT_TYPE_GENERAL |           | 1000   | USD   | true   | TRANSFER_TYPE_AMM_SUBACCOUNT_LOW |
-      | vamm3 | ACCOUNT_TYPE_GENERAL | vamm3-acc | ACCOUNT_TYPE_GENERAL |           | 1000   | USD   | true   | TRANSFER_TYPE_AMM_SUBACCOUNT_LOW |
-      | vamm4 | ACCOUNT_TYPE_GENERAL | vamm4-acc | ACCOUNT_TYPE_GENERAL |           | 1000   | USD   | true   | TRANSFER_TYPE_AMM_SUBACCOUNT_LOW |
-      | vamm5 | ACCOUNT_TYPE_GENERAL | vamm5-acc | ACCOUNT_TYPE_GENERAL |           | 1000   | USD   | true   | TRANSFER_TYPE_AMM_SUBACCOUNT_LOW |
-      | vamm6 | ACCOUNT_TYPE_GENERAL | vamm6-acc | ACCOUNT_TYPE_GENERAL |           | 1000   | USD   | true   | TRANSFER_TYPE_AMM_SUBACCOUNT_LOW |
+  # @VAMM
+  # Scenario: 0090-VAMM-005:  When market.amm.minCommitmentQuantum is 1000, mid price of the market 100, a user with 1000 USDT is able to create a vAMM with commitment 100, and any other combination of settings.
+  #   Given the parties deposit on asset's general account the following amount:
+  #     | party  | asset | amount |
+  #     | lp1    | USD   | 100000 |
+  #     | lp2    | USD   | 100000 |
+  #     | lp3    | USD   | 100000 |
+  #     | party1 | USD   | 100000 |
+  #     | party2 | USD   | 100000 |
+  #     | party3 | USD   | 100000 |
+  #     | vamm1  | USD   | 100000 |
+  #     | vamm2  | USD   | 100000 |
+  #     | vamm3  | USD   | 100000 |
+  #     | vamm4  | USD   | 100000 |
+  #     | vamm5  | USD   | 100000 |
+  #     | vamm6  | USD   | 100000 |
+  #     | vamm7  | USD   | 100000 |
+
+  #   When the parties submit the following liquidity provision:
+  #     | id   | party | market id | commitment amount | fee   | lp type    |
+  #     | lp_1 | lp1   | ETH/MAR22 | 600               | 0.02  | submission |
+  #     | lp_2 | lp2   | ETH/MAR22 | 400               | 0.015 | submission |
+  #   Then the network moves ahead "4" blocks
+  #   And the current epoch is "0"
+
+  #   And the parties place the following orders:
+  #     | party  | market id | side | volume | price | resulting trades | type       | tif     | reference |
+  #     | party3 | ETH/MAR22 | buy  | 10     | 85    | 0                | TYPE_LIMIT | TIF_GTC |           |
+  #     | party1 | ETH/MAR22 | buy  | 10     | 90    | 0                | TYPE_LIMIT | TIF_GTC |           |
+  #     | party1 | ETH/MAR22 | buy  | 1      | 100   | 0                | TYPE_LIMIT | TIF_GTC |           |
+  #     | party2 | ETH/MAR22 | sell | 10     | 110   | 0                | TYPE_LIMIT | TIF_GTC |           |
+  #     | party2 | ETH/MAR22 | sell | 1      | 100   | 0                | TYPE_LIMIT | TIF_GTC |           |
+  #     | party3 | ETH/MAR22 | sell | 1      | 120   | 0                | TYPE_LIMIT | TIF_GTC |           |
+  #     | lp1    | ETH/MAR22 | buy  | 10     | 95    | 0                | TYPE_LIMIT | TIF_GTC | lp1-b     |
+  #     | lp1    | ETH/MAR22 | sell | 10     | 105   | 0                | TYPE_LIMIT | TIF_GTC | lp1-s     |
+  #   When the opening auction period ends for market "ETH/MAR22"
+  #   Then the following trades should be executed:
+  #     | buyer  | price | size | seller |
+  #     | party1 | 100   | 1    | party2 |
+
+  #   And the market data for the market "ETH/MAR22" should be:
+  #     | mark price | trading mode            | horizon | min bound | max bound | target stake | supplied stake | open interest | ref price | mid price | static mid price |
+  #     | 100        | TRADING_MODE_CONTINUOUS | 3600    | 94        | 106       | 39           | 1000           | 1             | 100       | 100       | 100              |
+
+  #   When the parties submit the following AMM:
+  #     | party | market id | amount | slippage | base | lower bound | upper bound | lower leverage | upper leverage | proposed fee |
+  #     | vamm1 | ETH/MAR22 | 100000  | 0.1      | 100  | 85          | 150         | 0.25               | 0.25               | 0.01         |
+  #   Then the AMM pool status should be:
+  #     | party | market id | amount | status        | base | lower bound | lower leverage | upper bound | upper leverage |
+  #     | vamm1 | ETH/MAR22 | 100000  | STATUS_ACTIVE | 100  | 85          | 0.25               | 150         | 0.25               |
+
+  #   When the parties submit the following AMM:
+  #     | party | market id | amount | slippage | base | lower bound | lower leverage | error                        | proposed fee |
+  #     | vamm2 | ETH/MAR22 | 100000  | 0.1      | 90   | 85          | 0.25               | rebase target outside bounds | 0.01         |
+  #   # can't rebase because the target is 100 and thats outside of its bounds given there is no upper
+  #   Then the AMM pool status should be:
+  #     | party | market id | amount | status          | base | lower bound | lower leverage | reason                      |
+  #     | vamm2 | ETH/MAR22 | 100000  | STATUS_REJECTED | 90  | 85          | 0.25                | STATUS_REASON_CANNOT_REBASE |
+
+  #   When the parties submit the following AMM:
+  #     | party | market id | amount | slippage | base | upper bound | upper leverage | error                        | proposed fee |
+  #     | vamm3 | ETH/MAR22 | 100000  | 0.1      | 110  | 150         | 0.25               | rebase target outside bounds | 0.01         |
+  #   Then the AMM pool status should be:
+  #     | party | market id | amount | status          | base | upper bound | upper leverage | reason                      |
+  #     | vamm3 | ETH/MAR22 | 100000  | STATUS_REJECTED | 110  | 150         | 0.25               | STATUS_REASON_CANNOT_REBASE |
+
+  #   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         |
+  #   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                |
+
+  #   When the parties submit the following AMM:
+  #     | party | market id | amount | slippage | base | upper bound | upper leverage | proposed fee |
+  #     | vamm5 | ETH/MAR22 | 100000  | 0.1      | 99   | 101         | 0.02               |  0.01        |
+  #   Then the AMM pool status should be:
+  #     | party | market id | amount | status          | base | upper bound | upper leverage |
+  #     | vamm5 | ETH/MAR22 | 100000  | STATUS_ACTIVE   | 99  | 101          | 0.02               |
+
+  #   When the parties submit the following AMM:
+  #     | party | market id | amount | slippage | base | lower bound | upper bound | lower leverage | upper leverage | proposed fee |
+  #     | vamm6 | ETH/MAR22 | 100000  | 0.001    | 101  | 95          | 105         | 0.01               | 0.01               | 0.01         |
+  #   Then the AMM pool status should be:
+  #     | party | market id | amount | status        | base | lower bound | lower leverage | upper bound | upper leverage |
+  #     | vamm6 | ETH/MAR22 | 100000  | STATUS_ACTIVE | 101  | 95          | 0.01               | 105         | 0.01               |
+
+  #   When the parties submit the following AMM:
+  #     | party | market id | amount | slippage | base | lower bound | lower leverage | proposed fee |
+  #     | vamm7 | ETH/MAR22 | 100000  | 0.01     | 110  | 99          | 0.1                | 0.01         |
+  #   Then the AMM pool status should be:
+  #     | party | market id | amount | status          | base | lower bound | lower leverage | 
+  #     | vamm7 | ETH/MAR22 | 100000  | STATUS_ACTIVE   | 110  | 99          | 0.1                | 
+
+  #   And set the following AMM sub account aliases:
+  #     | party | market id | alias     |
+  #     | vamm1 | ETH/MAR22 | vamm1-acc |
+  #     | vamm2 | ETH/MAR22 | vamm2-acc |
+  #     | vamm3 | ETH/MAR22 | vamm3-acc |
+  #     | vamm4 | ETH/MAR22 | vamm4-acc |
+  #     | vamm5 | ETH/MAR22 | vamm5-acc |
+  #     | vamm6 | ETH/MAR22 | vamm6-acc |
+  #   And the following transfers should happen:
+  #     | from  | from account         | to        | to account           | market id | amount | asset | is amm | type                             |
+  #     | vamm1 | ACCOUNT_TYPE_GENERAL | vamm1-acc | ACCOUNT_TYPE_GENERAL |           | 1000   | USD   | true   | TRANSFER_TYPE_AMM_SUBACCOUNT_LOW |
+  #     | vamm2 | ACCOUNT_TYPE_GENERAL | vamm2-acc | ACCOUNT_TYPE_GENERAL |           | 1000   | USD   | true   | TRANSFER_TYPE_AMM_SUBACCOUNT_LOW |
+  #     | vamm3 | ACCOUNT_TYPE_GENERAL | vamm3-acc | ACCOUNT_TYPE_GENERAL |           | 1000   | USD   | true   | TRANSFER_TYPE_AMM_SUBACCOUNT_LOW |
+  #     | vamm4 | ACCOUNT_TYPE_GENERAL | vamm4-acc | ACCOUNT_TYPE_GENERAL |           | 1000   | USD   | true   | TRANSFER_TYPE_AMM_SUBACCOUNT_LOW |
+  #     | vamm5 | ACCOUNT_TYPE_GENERAL | vamm5-acc | ACCOUNT_TYPE_GENERAL |           | 1000   | USD   | true   | TRANSFER_TYPE_AMM_SUBACCOUNT_LOW |
+  #     | vamm6 | ACCOUNT_TYPE_GENERAL | vamm6-acc | ACCOUNT_TYPE_GENERAL |           | 1000   | USD   | true   | TRANSFER_TYPE_AMM_SUBACCOUNT_LOW |
 
diff --git a/core/integration/features/amm/0090-VAMM-022.feature b/core/integration/features/amm/0090-VAMM-022.feature
index bf069f9e497..a99b3cecd5d 100644
--- a/core/integration/features/amm/0090-VAMM-022.feature
+++ b/core/integration/features/amm/0090-VAMM-022.feature
@@ -61,7 +61,7 @@ Feature: Test vAMM cancellation without position works as expected.
       | party1 | USD   | 100000 |
       | party2 | USD   | 100000 |
       | party3 | USD   | 100000 |
-      | vamm1  | USD   | 1000   |
+      | vamm1  | USD   | 100000 |
 
     When the parties submit the following liquidity provision:
       | id   | party | market id | commitment amount | fee   | lp type    |
@@ -98,21 +98,21 @@ Feature: Test vAMM cancellation without position works as expected.
     # Now submit our vAMM, no trades should happen
     Then the parties submit the following AMM:
       | party | market id | amount | slippage | base | lower bound | upper bound | lower leverage | upper leverage | proposed fee |
-      | vamm1 | ETH/MAR22 | 1000   | 0.1      | 100  | 85          | 150         | 0.25               | 0.25               | 0.01         |
+      | vamm1 | ETH/MAR22 | 100000 | 0.1      | 100  | 85          | 150         | 0.25               | 0.25               | 0.01         |
     Then the AMM pool status should be:
       | party | market id | amount | status        | base | lower bound | upper bound | lower leverage | upper leverage |
-      | vamm1 | ETH/MAR22 | 1000   | STATUS_ACTIVE | 100  | 85          | 150         | 0.25               | 0.25               |
+      | vamm1 | ETH/MAR22 | 100000 | STATUS_ACTIVE | 100  | 85          | 150         | 0.25               | 0.25               |
 
     And set the following AMM sub account aliases:
       | party | market id | alias     |
       | vamm1 | ETH/MAR22 | vamm1-acc |
     And the following transfers should happen:
       | from  | from account         | to        | to account           | market id | amount | asset | is amm | type                             |
-      | vamm1 | ACCOUNT_TYPE_GENERAL | vamm1-acc | ACCOUNT_TYPE_GENERAL |           | 1000   | USD   | true   | TRANSFER_TYPE_AMM_SUBACCOUNT_LOW |
+      | vamm1 | ACCOUNT_TYPE_GENERAL | vamm1-acc | ACCOUNT_TYPE_GENERAL |           | 100000   | USD   | true   | TRANSFER_TYPE_AMM_SUBACCOUNT_LOW |
     And the parties should have the following account balances:
       | party     | asset | market id | general | margin | is amm |
       | vamm1     | USD   |           | 0       |        |        |
-      | vamm1-acc | USD   | ETH/MAR22 | 1000    |        | true   |
+      | vamm1-acc | USD   | ETH/MAR22 | 100000  |        | true   |
 
     # Now cancel with reduce-only
     When the parties cancel the following AMM:
@@ -120,22 +120,22 @@ Feature: Test vAMM cancellation without position works as expected.
       | vamm1 | ETH/MAR22 | METHOD_REDUCE_ONLY |
     Then the AMM pool status should be:
       | party | market id | amount | status             | base | lower bound | upper bound | lower leverage | upper leverage |
-      | vamm1 | ETH/MAR22 | 1000   | STATUS_REDUCE_ONLY | 100  | 85          | 150         | 0.25               | 0.25               |
+      | vamm1 | ETH/MAR22 | 100000   | STATUS_REDUCE_ONLY | 100  | 85          | 150         | 0.25               | 0.25               |
     # Balance is not yet released
     And the parties should have the following account balances:
       | party     | asset | market id | general | margin | is amm |
       | vamm1     | USD   |           | 0       |        |        |
-      | vamm1-acc | USD   | ETH/MAR22 | 1000    |        | true   |
+      | vamm1-acc | USD   | ETH/MAR22 | 100000  |        | true   |
 
     # Now trigger a MTM settlement, this is when we see the status updated to cancelled and the funds get released.
     When the network moves ahead "1" blocks
     Then the AMM pool status should be:
       | party | market id | amount | status           | base | lower bound | upper bound | lower leverage | upper leverage |
-      | vamm1 | ETH/MAR22 | 1000   | STATUS_CANCELLED | 100  | 85          | 150         | 0.25               | 0.25               |
+      | vamm1 | ETH/MAR22 | 100000   | STATUS_CANCELLED | 100  | 85          | 150         | 0.25               | 0.25               |
     Then the following transfers should happen:
       | from      | from account         | to    | to account           | market id | amount | asset | is amm | type                                 |
-      | vamm1-acc | ACCOUNT_TYPE_GENERAL | vamm1 | ACCOUNT_TYPE_GENERAL |           | 1000   | USD   | true   | TRANSFER_TYPE_AMM_SUBACCOUNT_RELEASE |
+      | vamm1-acc | ACCOUNT_TYPE_GENERAL | vamm1 | ACCOUNT_TYPE_GENERAL |           | 100000   | USD   | true   | TRANSFER_TYPE_AMM_SUBACCOUNT_RELEASE |
     And the parties should have the following account balances:
       | party     | asset | market id | general | margin | is amm |
-      | vamm1     | USD   |           | 1000    |        |        |
+      | vamm1     | USD   |           | 100000  |        |        |
       | vamm1-acc | USD   | ETH/MAR22 | 0       |        | true   |
diff --git a/core/integration/features/amm/0090-VAMM-023.feature b/core/integration/features/amm/0090-VAMM-023.feature
index 7d4bcc54a9a..be217433d00 100644
--- a/core/integration/features/amm/0090-VAMM-023.feature
+++ b/core/integration/features/amm/0090-VAMM-023.feature
@@ -61,7 +61,7 @@ Feature: Test cancelled vAMM becomes active on amend.
       | party1 | USD   | 100000 |
       | party2 | USD   | 100000 |
       | party3 | USD   | 100000 |
-      | vamm1  | USD   | 1000   |
+      | vamm1  | USD   | 100000 |
 
     When the parties submit the following liquidity provision:
       | id   | party | market id | commitment amount | fee   | lp type    |
@@ -98,21 +98,21 @@ Feature: Test cancelled vAMM becomes active on amend.
     # Now submit our vAMM, no trades should happen
     Then the parties submit the following AMM:
       | party | market id | amount | slippage | base | lower bound | upper bound | lower leverage | upper leverage | proposed fee |
-      | vamm1 | ETH/MAR22 | 1000   | 0.1      | 100  | 85          | 150         | 0.25               | 0.25               | 0.01         |
+      | vamm1 | ETH/MAR22 | 100000 | 0.1      | 100  | 85          | 150         | 0.25               | 0.25               | 0.01         |
     Then the AMM pool status should be:
       | party | market id | amount | status        | base | lower bound | upper bound | lower leverage | upper leverage |
-      | vamm1 | ETH/MAR22 | 1000   | STATUS_ACTIVE | 100  | 85          | 150         | 0.25               | 0.25               |
+      | vamm1 | ETH/MAR22 | 100000 | STATUS_ACTIVE | 100  | 85          | 150         | 0.25               | 0.25               |
 
     And set the following AMM sub account aliases:
       | party | market id | alias     |
       | vamm1 | ETH/MAR22 | vamm1-acc |
     And the following transfers should happen:
       | from  | from account         | to        | to account           | market id | amount | asset | is amm | type                             |
-      | vamm1 | ACCOUNT_TYPE_GENERAL | vamm1-acc | ACCOUNT_TYPE_GENERAL |           | 1000   | USD   | true   | TRANSFER_TYPE_AMM_SUBACCOUNT_LOW |
+      | vamm1 | ACCOUNT_TYPE_GENERAL | vamm1-acc | ACCOUNT_TYPE_GENERAL |           | 100000 | USD   | true   | TRANSFER_TYPE_AMM_SUBACCOUNT_LOW |
     And the parties should have the following account balances:
       | party     | asset | market id | general | margin | is amm |
       | vamm1     | USD   |           | 0       |        |        |
-      | vamm1-acc | USD   | ETH/MAR22 | 1000    |        | true   |
+      | vamm1-acc | USD   | ETH/MAR22 | 100000  |        | true   |
 
     # Now cancel with reduce-only
     When the parties cancel the following AMM:
@@ -120,12 +120,12 @@ Feature: Test cancelled vAMM becomes active on amend.
       | vamm1 | ETH/MAR22 | METHOD_REDUCE_ONLY |
     Then the AMM pool status should be:
       | party | market id | amount | status             | base | lower bound | upper bound | lower leverage | upper leverage |
-      | vamm1 | ETH/MAR22 | 1000   | STATUS_REDUCE_ONLY | 100  | 85          | 150         | 0.25               | 0.25               |
+      | vamm1 | ETH/MAR22 | 100000 | STATUS_REDUCE_ONLY | 100  | 85          | 150         | 0.25               | 0.25               |
     # Balance is not yet released
     And the parties should have the following account balances:
       | party     | asset | market id | general | margin | is amm |
       | vamm1     | USD   |           | 0       |        |        |
-      | vamm1-acc | USD   | ETH/MAR22 | 1000    |        | true   |
+      | vamm1-acc | USD   | ETH/MAR22 | 100000  |        | true   |
 
     # Now amend the reduce-only vAMM submission, and check to see if its status returns back to active
     When the parties amend the following AMM:
@@ -133,18 +133,18 @@ Feature: Test cancelled vAMM becomes active on amend.
       | vamm1 | ETH/MAR22 | 0.1      | 105  | 90          | 155         |
     Then the AMM pool status should be:
       | party | market id | amount | status        | base | lower bound | upper bound | lower leverage | upper leverage |
-      | vamm1 | ETH/MAR22 | 1000   | STATUS_ACTIVE | 105  | 90          | 155         | 0.25               | 0.25               |
+      | vamm1 | ETH/MAR22 | 100000 | STATUS_ACTIVE | 105  | 90          | 155         | 0.25               | 0.25               |
 
     # Now trigger a MTM settlement, this should not change anything, whereas without the amend it'd move the vAMM to the cancelled status.
     When the network moves ahead "1" blocks
     Then the AMM pool status should be:
       | party | market id | amount | status        | base | lower bound | upper bound | lower leverage | upper leverage |
-      | vamm1 | ETH/MAR22 | 1000   | STATUS_ACTIVE | 105  | 90          | 155         | 0.25               | 0.25               |
+      | vamm1 | ETH/MAR22 | 100000 | STATUS_ACTIVE | 105  | 90          | 155         | 0.25               | 0.25               |
     And the parties should have the following account balances:
       | party     | asset | market id | general | margin | is amm |
       | vamm1     | USD   |           | 0       |        |        |
-      | vamm1-acc | USD   | ETH/MAR22 | 1000    |        | true   |
+      | vamm1-acc | USD   | ETH/MAR22 | 100000  |        | true   |
     # The mark price has now moved to 105
     And the market data for the market "ETH/MAR22" should be:
       | mark price | trading mode            | target stake | supplied stake | open interest | ref price | mid price | static mid price |
-      | 105        | TRADING_MODE_CONTINUOUS | 461          | 1000           | 11            | 104       | 100       | 100              |
+      | 105        | TRADING_MODE_CONTINUOUS | 461          | 1000           | 11            | 104       | 105       | 105              |
diff --git a/core/integration/features/amm/0090-VAMM-024-026.feature b/core/integration/features/amm/0090-VAMM-024-026.feature
index 2e1dcc7c1b9..05d96d5cb6f 100644
--- a/core/integration/features/amm/0090-VAMM-024-026.feature
+++ b/core/integration/features/amm/0090-VAMM-024-026.feature
@@ -59,7 +59,7 @@ Feature: When market.amm.minCommitmentQuantum is 1000, mid price of the market 1
       | party3 | USD   | 1000000 |
       | party4 | USD   | 1000000 |
       | party5 | USD   | 1000000 |
-      | vamm1  | USD   | 10000   |
+      | vamm1  | USD   | 30000   |
 
     When the parties submit the following liquidity provision:
       | id   | party | market id | commitment amount | fee   | lp type    |
@@ -84,17 +84,17 @@ Feature: When market.amm.minCommitmentQuantum is 1000, mid price of the market 1
       | 100        | TRADING_MODE_CONTINUOUS | 39           | 1000           | 1             | 100       | 100       | 100              |
     When the parties submit the following AMM:
       | party | market id | amount | slippage | base | lower bound | upper bound | lower leverage | upper leverage | proposed fee |
-      | vamm1 | ETH/MAR22 | 10000  | 0.1      | 100  | 85          | 150         | 4              | 4              | 0.01         |
+      | vamm1 | ETH/MAR22 | 30000  | 0.1      | 100  | 85          | 150         | 4              | 4              | 0.01         |
     Then the AMM pool status should be:
       | party | market id | amount | status        | base | lower bound | upper bound | lower leverage | upper leverage |
-      | vamm1 | ETH/MAR22 | 10000  | STATUS_ACTIVE | 100  | 85          | 150         | 4              | 4              |
+      | vamm1 | ETH/MAR22 | 30000  | STATUS_ACTIVE | 100  | 85          | 150         | 4              | 4              |
 
     And set the following AMM sub account aliases:
       | party | market id | alias    |
       | vamm1 | ETH/MAR22 | vamm1-id |
     And the following transfers should happen:
       | from  | from account         | to       | to account           | market id | amount | asset | is amm | type                             |
-      | vamm1 | ACCOUNT_TYPE_GENERAL | vamm1-id | ACCOUNT_TYPE_GENERAL |           | 10000  | USD   | true   | TRANSFER_TYPE_AMM_SUBACCOUNT_LOW |
+      | vamm1 | ACCOUNT_TYPE_GENERAL | vamm1-id | ACCOUNT_TYPE_GENERAL |           | 30000  | USD   | true   | TRANSFER_TYPE_AMM_SUBACCOUNT_LOW |
 
   @VAMM
   Scenario: 0090-VAMM-024: If other traders trade to move the market mid price to 140 the vAMM has a short position.
@@ -102,21 +102,22 @@ Feature: When market.amm.minCommitmentQuantum is 1000, mid price of the market 1
       | party  | market id | side | volume | price | resulting trades | type       | tif     |
       | party4 | ETH/MAR22 | buy  | 4      | 120   | 1                | TYPE_LIMIT | TIF_GTC |
     # see the trades that make the vAMM go short
+
     Then the following trades should be executed:
       | buyer  | price | size | seller   | is amm |
-      | party4 | 102   | 4    | vamm1-id | true   |
+      | party4 | 100   | 4    | vamm1-id | true   |
 
     When the network moves ahead "1" blocks
     Then the market data for the market "ETH/MAR22" should be:
       | mark price | trading mode            | mid price | static mid price |
-      | 102        | TRADING_MODE_CONTINUOUS | 106       | 106              |
+      | 100        | TRADING_MODE_CONTINUOUS | 102       | 102              |
     And the parties should have the following profit and loss:
       | party    | volume | unrealised pnl | realised pnl | is amm |
       | party4   | 4      | 0              | 0            |        |
       | vamm1-id | -4     | 0              | 0            | true   |
     And the AMM pool status should be:
       | party | market id | amount | status        | base | lower bound | upper bound | lower leverage | upper leverage |
-      | vamm1 | ETH/MAR22 | 10000  | STATUS_ACTIVE | 100  | 85          | 150         | 4              | 4              |
+      | vamm1 | ETH/MAR22 | 30000  | STATUS_ACTIVE | 100  | 85          | 150         | 4              | 4              |
 
   @VAMM
   Scenario: 0090-VAMM-025: If the vAMM is then amended such that it has a new base price of 140 it should attempt to place a trade to rebalance it's position to 0 at a mid price of 140. If that trade can execute with the slippage as configured in the request then the transaction is accepted.
@@ -126,19 +127,19 @@ Feature: When market.amm.minCommitmentQuantum is 1000, mid price of the market 1
     # see the trades that make the vAMM go short
     Then the following trades should be executed:
       | buyer  | price | size | seller   | is amm |
-      | party4 | 102   | 4    | vamm1-id | true   |
+      | party4 | 100   | 4    | vamm1-id | true   |
 
     When the network moves ahead "1" blocks
     Then the market data for the market "ETH/MAR22" should be:
       | mark price | trading mode            | mid price | static mid price |
-      | 102        | TRADING_MODE_CONTINUOUS | 106       | 106              |
+      | 100        | TRADING_MODE_CONTINUOUS | 102       | 102              |
     And the parties should have the following profit and loss:
       | party    | volume | unrealised pnl | realised pnl | is amm |
       | party4   | 4      | 0              | 0            |        |
       | vamm1-id | -4     | 0              | 0            | true   |
     And the AMM pool status should be:
       | party | market id | amount | status        | base | lower bound | upper bound | lower leverage | upper leverage |
-      | vamm1 | ETH/MAR22 | 10000  | STATUS_ACTIVE | 100  | 85          | 150         | 4              | 4              |
+      | vamm1 | ETH/MAR22 | 30000  | STATUS_ACTIVE | 100  | 85          | 150         | 4              | 4              |
 
     # Now amend the vAMM in a way that gets accepted.
     When the parties amend the following AMM:
@@ -146,16 +147,16 @@ Feature: When market.amm.minCommitmentQuantum is 1000, mid price of the market 1
       | vamm1 | ETH/MAR22 | 0.5      | 140  | 90          | 155         |
     Then the AMM pool status should be:
       | party | market id | amount | status        | base | lower bound | upper bound | lower leverage | upper leverage |
-      | vamm1 | ETH/MAR22 | 10000  | STATUS_ACTIVE | 140  | 90          | 155         | 4              | 4              |
+      | vamm1 | ETH/MAR22 | 30000  | STATUS_ACTIVE | 140  | 90          | 155         | 4              | 4              |
     # ensure the vamm closed its position
     When the network moves ahead "1" blocks
     Then the market data for the market "ETH/MAR22" should be:
       | mark price | trading mode            | mid price | static mid price |
-      | 150        | TRADING_MODE_CONTINUOUS | 142       | 142              |
+      | 150        | TRADING_MODE_CONTINUOUS | 141       | 141              |
     And the parties should have the following profit and loss:
       | party    | volume | unrealised pnl | realised pnl | is amm |
-      | party4   | 4      | 192            | 0            |        |
-      | vamm1-id | -4     | 0              | -192         | true   |
+      | party4   | 4      | 200            | 0            |        |
+      | vamm1-id | -4     | 0              | -200         | true   |
 
   @VAMM
   Scenario: 0090-VAMM-026: If the trade cannot execute with the slippage as configured in the request then the transaction is rejected and no changes to the vAMM are made.
@@ -165,19 +166,19 @@ Feature: When market.amm.minCommitmentQuantum is 1000, mid price of the market 1
     # see the trades that make the vAMM go short
     Then the following trades should be executed:
       | buyer  | price | size | seller   | is amm |
-      | party4 | 102   | 4    | vamm1-id | true   |
+      | party4 | 100   | 4    | vamm1-id | true   |
 
     When the network moves ahead "1" blocks
     Then the market data for the market "ETH/MAR22" should be:
       | mark price | trading mode            | mid price | static mid price |
-      | 102        | TRADING_MODE_CONTINUOUS | 106       | 106              |
+      | 100        | TRADING_MODE_CONTINUOUS | 102       | 102              |
     And the parties should have the following profit and loss:
       | party    | volume | unrealised pnl | realised pnl | is amm |
       | party4   | 4      | 0              | 0            |        |
       | vamm1-id | -4     | 0              | 0            | true   |
     And the AMM pool status should be:
       | party | market id | amount | status        | base | lower bound | upper bound | lower leverage | upper leverage |
-      | vamm1 | ETH/MAR22 | 10000  | STATUS_ACTIVE | 100  | 85          | 150         | 4              | 4              |
+      | vamm1 | ETH/MAR22 | 30000  | STATUS_ACTIVE | 100  | 85          | 150         | 4              | 4              |
 
     # Now amend the vAMM that doesn't trade and gets rejected
     When the parties amend the following AMM:
@@ -186,7 +187,7 @@ Feature: When market.amm.minCommitmentQuantum is 1000, mid price of the market 1
     # ensure the status of the vAMM remains the same (if no update event is sent, this test will pass even if the vAMM was in some way changed)
     Then the AMM pool status should be:
       | party | market id | amount | status        | base | lower bound | upper bound | lower leverage | upper leverage |
-      | vamm1 | ETH/MAR22 | 10000  | STATUS_ACTIVE | 100  | 85          | 150         | 4              | 4              |
+      | vamm1 | ETH/MAR22 | 30000  | STATUS_ACTIVE | 100  | 85          | 150         | 4              | 4              |
 
     # To account for a passing test caused by an event not being sent out, cancel the vAMM and check the status
     When the parties cancel the following AMM:
@@ -194,4 +195,4 @@ Feature: When market.amm.minCommitmentQuantum is 1000, mid price of the market 1
       | vamm1 | ETH/MAR22 | METHOD_REDUCE_ONLY |
     Then the AMM pool status should be:
       | party | market id | amount | status             | base | lower bound | upper bound | lower leverage | upper leverage |
-      | vamm1 | ETH/MAR22 | 10000  | STATUS_REDUCE_ONLY | 100  | 85          | 150         | 4              | 4              |
+      | vamm1 | ETH/MAR22 | 30000  | STATUS_REDUCE_ONLY | 100  | 85          | 150         | 4              | 4              |
diff --git a/core/integration/features/amm/0090-VAMM-031.feature b/core/integration/features/amm/0090-VAMM-031.feature
index a062d7aef5b..2d49d224efe 100644
--- a/core/integration/features/amm/0090-VAMM-031.feature
+++ b/core/integration/features/amm/0090-VAMM-031.feature
@@ -67,7 +67,7 @@ Feature: vAMM behaviour when a market settles
       | party3 | USD   | 1000000 |
       | party4 | USD   | 1000000 |
       | party5 | USD   | 1000000 |
-      | vamm1  | USD   | 10000   |
+      | vamm1  | USD   | 30000   |
 
     When the parties submit the following liquidity provision:
       | id   | party | market id | commitment amount | fee   | lp type    |
@@ -94,17 +94,17 @@ Feature: vAMM behaviour when a market settles
       | 100        | TRADING_MODE_CONTINUOUS | 39           | 1000           | 1             | 100       | 100       | 100              |
     When the parties submit the following AMM:
       | party | market id | amount | slippage | base | lower bound | upper bound | lower leverage | upper leverage | proposed fee |
-      | vamm1 | ETH/MAR22 | 10000  | 0.1      | 100  | 85          | 150         | 4              | 4              | 0.01         |
+      | vamm1 | ETH/MAR22 | 30000  | 0.1      | 100  | 85          | 150         | 4              | 4              | 0.01         |
     Then the AMM pool status should be:
       | party | market id | amount | status        | base | lower bound | upper bound | lower leverage | upper leverage |
-      | vamm1 | ETH/MAR22 | 10000  | STATUS_ACTIVE | 100  | 85          | 150         | 4              | 4              |
+      | vamm1 | ETH/MAR22 | 30000  | STATUS_ACTIVE | 100  | 85          | 150         | 4              | 4              |
 
     And set the following AMM sub account aliases:
       | party | market id | alias    |
       | vamm1 | ETH/MAR22 | vamm1-id |
     And the following transfers should happen:
       | from  | from account         | to       | to account           | market id | amount  | asset | is amm | type                             |
-      | vamm1 | ACCOUNT_TYPE_GENERAL | vamm1-id | ACCOUNT_TYPE_GENERAL |           | 10000   | USD   | true   | TRANSFER_TYPE_AMM_SUBACCOUNT_LOW |
+      | vamm1 | ACCOUNT_TYPE_GENERAL | vamm1-id | ACCOUNT_TYPE_GENERAL |           | 30000   | USD   | true   | TRANSFER_TYPE_AMM_SUBACCOUNT_LOW |
 
   @VAMM
   Scenario Outline: 0090-VAMM-031: When an AMM is active on a market at time of settlement with a position in a well collateralised state, the market can settle successfully and then all funds on the AMM key are transferred back to the main party's account.
@@ -119,14 +119,14 @@ Feature: vAMM behaviour when a market settles
     When the network moves ahead "1" blocks
     Then the market data for the market "ETH/MAR22" should be:
       | mark price | trading mode            | mid price | static mid price | supplied stake |
-      | 100        | TRADING_MODE_CONTINUOUS | 102       | 102              | 1000           |
+      | 100        | TRADING_MODE_CONTINUOUS | 101       | 101              | 1000           |
     And the parties should have the following profit and loss:
       | party    | volume | unrealised pnl | realised pnl | is amm |
       | party4   | 1      | 0              | 0            |        |
       | vamm1-id | -1     | 0              | 0            | true   |
     And the AMM pool status should be:
       | party | market id | amount  | status        | base | lower bound | upper bound | lower leverage | upper leverage |
-      | vamm1 | ETH/MAR22 | 10000   | STATUS_ACTIVE | 100  | 85          | 150         | 4              | 4              |
+      | vamm1 | ETH/MAR22 | 30000   | STATUS_ACTIVE | 100  | 85          | 150         | 4              | 4              |
 
     # No terminate && settle the market
     When the oracles broadcast data signed with "0xCAFECAFE":
@@ -136,7 +136,7 @@ Feature: vAMM behaviour when a market settles
     And the parties should have the following account balances:
       | party    | asset | market id | general | margin | is amm |
       | vamm1    | USD   |           | 0       |        |        |
-      | vamm1-id | USD   | ETH/MAR22 | 9791    | 210    | true   |
+      | vamm1-id | USD   | ETH/MAR22 | 29791   | 210    | true   |
 
     When the oracles broadcast data signed with "0xCAFECAFE":
       | name             | value          |
@@ -158,8 +158,8 @@ Feature: vAMM behaviour when a market settles
     # Different scenario's involving a final settlement: break even, profit and loss.
     Examples:
       | settle price | margin | amm balance | general balance |
-      | 106          | 204    | 9995        | 9995            | # settle price = market price: +1 from fees
-      | 105          | 205    | 9996        | 9996            | # settle price < market price: +1 from fees +1 from final settlement
-      | 107          | 203    | 9994        | 9994            | # settle price > market price: +1 from fees, -1 from final settlement
-      | 104          | 206    | 9997        | 9997            | # settle price < market price: +1 from fees +2 from final settlement
-      | 108          | 202    | 9993        | 9993             | # settle price > market price: +1 from fees, -2 from final settlement
+      | 105          | 205    | 29996       | 29996            | # settle price < market price: +1 from fees +1 from final settlement
+      | 107          | 203    | 29994       | 29994            | # settle price > market price: +1 from fees, -1 from final settlement
+      | 104          | 206    | 29997       | 29997            | # settle price < market price: +1 from fees +2 from final settlement
+      | 106          | 204    | 29995       | 29995            | # settle price = market price: +1 from fees
+      | 108          | 202    | 29993       | 29993           | # settle price > market price: +1 from fees, -2 from final settlement
diff --git a/core/integration/features/amm/0090-VAMM-032.feature b/core/integration/features/amm/0090-VAMM-032.feature
index 7fe78101c76..4db70a1e04b 100644
--- a/core/integration/features/amm/0090-VAMM-032.feature
+++ b/core/integration/features/amm/0090-VAMM-032.feature
@@ -67,7 +67,7 @@ Feature: vAMM behaviour when a market settles with distressed AMM.
       | party3 | USD   | 1000000 |
       | party4 | USD   | 1000000 |
       | party5 | USD   | 1000000 |
-      | vamm1  | USD   | 10000   |
+      | vamm1  | USD   | 30000   |
 
     When the parties submit the following liquidity provision:
       | id   | party | market id | commitment amount | fee   | lp type    |
@@ -92,17 +92,17 @@ Feature: vAMM behaviour when a market settles with distressed AMM.
       | 100        | TRADING_MODE_CONTINUOUS | 39           | 1000           | 1             | 100       | 100       | 100              |
     When the parties submit the following AMM:
       | party | market id | amount | slippage | base | lower bound | upper bound | lower leverage | upper leverage | proposed fee |
-      | vamm1 | ETH/MAR22 | 10000  | 0.1      | 100  | 85          | 150         | 4              | 4              | 0.01         |
+      | vamm1 | ETH/MAR22 | 30000  | 0.1      | 100  | 85          | 150         | 4              | 4              | 0.01         |
     Then the AMM pool status should be:
       | party | market id | amount | status        | base | lower bound | upper bound | lower leverage | upper leverage |
-      | vamm1 | ETH/MAR22 | 10000  | STATUS_ACTIVE | 100  | 85          | 150         | 4              | 4              |
+      | vamm1 | ETH/MAR22 | 30000  | STATUS_ACTIVE | 100  | 85          | 150         | 4              | 4              |
 
     And set the following AMM sub account aliases:
       | party | market id | alias    |
       | vamm1 | ETH/MAR22 | vamm1-id |
     And the following transfers should happen:
       | from  | from account         | to       | to account           | market id | amount | asset | is amm | type                             |
-      | vamm1 | ACCOUNT_TYPE_GENERAL | vamm1-id | ACCOUNT_TYPE_GENERAL |           | 10000  | USD   | true   | TRANSFER_TYPE_AMM_SUBACCOUNT_LOW |
+      | vamm1 | ACCOUNT_TYPE_GENERAL | vamm1-id | ACCOUNT_TYPE_GENERAL |           | 30000  | USD   | true   | TRANSFER_TYPE_AMM_SUBACCOUNT_LOW |
 
   @VAMM
   Scenario: 0090-VAMM-032: When an AMM is active on a market at time of settlement with a position in a well collateralised state, the market can settle successfully and then all funds on the AMM key are transferred back to the main party's account.
@@ -115,19 +115,19 @@ Feature: vAMM behaviour when a market settles with distressed AMM.
     Then the following trades should be executed:
       | buyer  | price | size | seller   | is amm |
       | party4 | 100   | 1    | vamm1-id | true   |
-      | party4 | 102   | 1    | vamm1-id | true   |
+      | party4 | 100   | 1    | vamm1-id | true   |
 
     When the network moves ahead "1" blocks
     Then the market data for the market "ETH/MAR22" should be:
       | mark price | trading mode            | mid price | static mid price | supplied stake | target stake |
-      | 102        | TRADING_MODE_CONTINUOUS | 131       | 131              | 1000           | 122          |
+      | 100        | TRADING_MODE_CONTINUOUS | 101       | 101              | 1000           | 119          |
     And the parties should have the following profit and loss:
       | party    | volume | unrealised pnl | realised pnl | is amm |
-      | party4   | 2      | 2             | 0            |        |
-      | vamm1-id | -2     | -2            | 0            | true   |
+      | party4   | 2      | 0             | 0            |        |
+      | vamm1-id | -2     | 0            | 0            | true   |
     And the AMM pool status should be:
       | party | market id | amount | status        | base | lower bound | upper bound | lower leverage | upper leverage |
-      | vamm1 | ETH/MAR22 | 10000  | STATUS_ACTIVE | 100  | 85          | 150         | 4              | 4              |
+      | vamm1 | ETH/MAR22 | 30000  | STATUS_ACTIVE | 100  | 85          | 150         | 4              | 4              |
 
     # No terminate && settle the market
     When the oracles broadcast data signed with "0xCAFECAFE":
@@ -137,7 +137,7 @@ Feature: vAMM behaviour when a market settles with distressed AMM.
     And the parties should have the following account balances:
       | party    | asset | market id | general | margin | is amm |
       | vamm1    | USD   |           | 0       |        |        |
-      | vamm1-id | USD   | ETH/MAR22 | 9571    | 429    | true   |
+      | vamm1-id | USD   | ETH/MAR22 | 29582   | 420    | true   |
 
     # Settlement price is ~9x mark price
     When the oracles broadcast data signed with "0xCAFECAFE":
@@ -149,16 +149,16 @@ Feature: vAMM behaviour when a market settles with distressed AMM.
     # verify the that the margin balance is released, and then the correct balance if transferred from the pool account back to the party.
     # We see fees on both trades, a MTM loss transfer, margin being allocated, then the loss transfer from the final settlement
     # and lastly a transfer of the general account back to the owner.
+    Then debug transfers
     And the following transfers should happen:
       | from     | from account            | to       | to account              | market id | amount | asset | is amm | type                                 |
       |          | ACCOUNT_TYPE_FEES_MAKER | vamm1-id | ACCOUNT_TYPE_GENERAL    | ETH/MAR22 | 1      | USD   | true   | TRANSFER_TYPE_MAKER_FEE_RECEIVE      |
       |          | ACCOUNT_TYPE_FEES_MAKER | vamm1-id | ACCOUNT_TYPE_GENERAL    | ETH/MAR22 | 1      | USD   | true   | TRANSFER_TYPE_MAKER_FEE_RECEIVE      |
-      | vamm1-id | ACCOUNT_TYPE_GENERAL    |          | ACCOUNT_TYPE_SETTLEMENT | ETH/MAR22 | 2      | USD   | true   | TRANSFER_TYPE_MTM_LOSS               |
-      | vamm1-id | ACCOUNT_TYPE_GENERAL    | vamm1-id | ACCOUNT_TYPE_MARGIN     | ETH/MAR22 | 429    | USD   | true   | TRANSFER_TYPE_MARGIN_LOW             |
-      | vamm1-id | ACCOUNT_TYPE_MARGIN     |          | ACCOUNT_TYPE_SETTLEMENT | ETH/MAR22 | 429    | USD   | true   | TRANSFER_TYPE_LOSS                   |
-      | vamm1-id | ACCOUNT_TYPE_GENERAL    |          | ACCOUNT_TYPE_SETTLEMENT | ETH/MAR22 | 1367   | USD   | true   | TRANSFER_TYPE_LOSS                   |
-      | vamm1-id | ACCOUNT_TYPE_GENERAL    | vamm1    | ACCOUNT_TYPE_GENERAL    |           | 8204   | USD   | true   | TRANSFER_TYPE_AMM_SUBACCOUNT_RELEASE |
+      | vamm1-id | ACCOUNT_TYPE_GENERAL    | vamm1-id | ACCOUNT_TYPE_MARGIN     | ETH/MAR22 | 420    | USD   | true   | TRANSFER_TYPE_MARGIN_LOW             |
+      | vamm1-id | ACCOUNT_TYPE_MARGIN     |          | ACCOUNT_TYPE_SETTLEMENT | ETH/MAR22 | 420    | USD   | true   | TRANSFER_TYPE_LOSS                   |
+      | vamm1-id | ACCOUNT_TYPE_GENERAL    |          | ACCOUNT_TYPE_SETTLEMENT | ETH/MAR22 | 1380   | USD   | true   | TRANSFER_TYPE_LOSS                   |
+      | vamm1-id | ACCOUNT_TYPE_GENERAL    | vamm1    | ACCOUNT_TYPE_GENERAL    |           | 28202  | USD   | true   | TRANSFER_TYPE_AMM_SUBACCOUNT_RELEASE |
     And the parties should have the following account balances:
       | party    | asset | market id | general | margin | is amm |
-      | vamm1    | USD   |           | 8204    |        |        |
+      | vamm1    | USD   |           | 28202   |        |        |
       | vamm1-id | USD   | ETH/MAR22 | 0       | 0      | true   |