You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This is a successor to #2372 that defines a simplified MVP of this feature for vAMM liquidity only.
This feature will create a version of Vega's vAMM that can pool or share the funds allocated to it across multiple vAMM commitments on markets that share the same settlement asset.
A new "virtual account" / sub-key type can exist representing a { vega pubkey, settlement asset } pair, rather than the { vega pubkey, market } pair that identifies current vAMM pools.
A user makes a commitment to the vAMM in the usual way, but a new option will allow them to specify that the commitment should use the shared liquidity pool for the asset (the default being a normal "exclusive liquidity" commitment).
All the shared liquiditty commitments for a given key and asset operate from the same sub-key and therefore access the same funds when allocating position margin.
When making a new commitment or updating the commitment size, funds are only added to the sub-key if the commitment amount is larger than the current general account balance of the key plus any position margin for that market.
Any user can transfer funds to the sub-key to increase its collateralisation, including to overcollateralise it. This does not change any commitment size, it just gives the shared pool more money. They have no way to get their funds back if they are not the owner.
Users who own the commitment can transfer funds from the sub-key to [their general account|any general account|any valid destination for a normal transfer] (whichever is easier to implement) as long as enough funds exist in the key's general account to complete the transfer.
When determining the amount of volume implied by the vAMM in a given price range:
For price ranges within the position reducing price range (i.e. between the curve's fair price and its base price), the volume implied for any given sub-range / price level is the volume implied by the base commitment size scaled by the current open position size as a fraction of total volume implied in the position reducing price range for the base commitment size.
For price ranges outside the position reducing price range the volume implied is the volume that would be implied for the base commitment size scaled by min( base_commitment_size, (general_account_balance + position_margin_balance - mtm_adjustment_see_below) / base_commitment_size ).
mtm_adjustment_see_below is the MTM gain/loss experienced by the pool's positions on that market since inception, this would need to be applied to keep the behaviour consistent with the current design IF we decide not to introduce scaling based on available collateral post MTM gains/losses everywhere
Price ranges including some prices in both must be split into two ranges and each calculated according to the rules above.
All other features work as for the normal vAMM, any transactions that interact with the vAMM can specify the appropriate sub-key, or if they usually specify a market, will need to send a market ID plus a flag/enum that specifies to use the shared/pooled vAMM.
Some APIs may be needed to ensure that all relevant information about the vAMM and its margin/liquidity state can be retrieved, but existing APIs should cover most or perhaps even all of what's needed.
The text was updated successfully, but these errors were encountered:
This is a successor to #2372 that defines a simplified MVP of this feature for vAMM liquidity only.
This feature will create a version of Vega's vAMM that can pool or share the funds allocated to it across multiple vAMM commitments on markets that share the same settlement asset.
A new "virtual account" / sub-key type can exist representing a { vega pubkey, settlement asset } pair, rather than the { vega pubkey, market } pair that identifies current vAMM pools.
A user makes a commitment to the vAMM in the usual way, but a new option will allow them to specify that the commitment should use the shared liquidity pool for the asset (the default being a normal "exclusive liquidity" commitment).
All the shared liquiditty commitments for a given key and asset operate from the same sub-key and therefore access the same funds when allocating position margin.
When making a new commitment or updating the commitment size, funds are only added to the sub-key if the commitment amount is larger than the current general account balance of the key plus any position margin for that market.
Any user can transfer funds to the sub-key to increase its collateralisation, including to overcollateralise it. This does not change any commitment size, it just gives the shared pool more money. They have no way to get their funds back if they are not the owner.
Users who own the commitment can transfer funds from the sub-key to [their general account|any general account|any valid destination for a normal transfer] (whichever is easier to implement) as long as enough funds exist in the key's general account to complete the transfer.
When determining the amount of volume implied by the vAMM in a given price range:
For price ranges within the position reducing price range (i.e. between the curve's fair price and its base price), the volume implied for any given sub-range / price level is the volume implied by the base commitment size scaled by the current open position size as a fraction of total volume implied in the position reducing price range for the base commitment size.
For price ranges outside the position reducing price range the volume implied is the volume that would be implied for the base commitment size scaled by
min( base_commitment_size, (general_account_balance + position_margin_balance - mtm_adjustment_see_below) / base_commitment_size )
.mtm_adjustment_see_below
is the MTM gain/loss experienced by the pool's positions on that market since inception, this would need to be applied to keep the behaviour consistent with the current design IF we decide not to introduce scaling based on available collateral post MTM gains/losses everywherePrice ranges including some prices in both must be split into two ranges and each calculated according to the rules above.
All other features work as for the normal vAMM, any transactions that interact with the vAMM can specify the appropriate sub-key, or if they usually specify a market, will need to send a market ID plus a flag/enum that specifies to use the shared/pooled vAMM.
Some APIs may be needed to ensure that all relevant information about the vAMM and its margin/liquidity state can be retrieved, but existing APIs should cover most or perhaps even all of what's needed.
The text was updated successfully, but these errors were encountered: