Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Spec for vAMM virtual / pooled / shared liquidity #2378

Open
barnabee opened this issue Oct 9, 2024 · 0 comments · May be fixed by #2380
Open

Spec for vAMM virtual / pooled / shared liquidity #2378

barnabee opened this issue Oct 9, 2024 · 0 comments · May be fixed by #2380

Comments

@barnabee
Copy link
Member

barnabee commented Oct 9, 2024

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.

@cdummett cdummett linked a pull request Oct 28, 2024 that will close this issue
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant