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.

Sign up for GitHub

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

Oracle-driven base price for vAMMs #2375

Merged
merged 5 commits into from
Oct 7, 2024
+42 −4
Merged

Oracle-driven base price for vAMMs #2375

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
5 commits
Select commit Hold shift + click to select a range
a32f38e
refactor: allow oracle-driven base price
witgaw Sep 26, 2024
a7ad4ff
refactor: clarify config vs value amendment
witgaw Sep 26, 2024
06042b5
refactor: allow oracles that are part of market definition already
witgaw Sep 27, 2024
46d4bc4
refactor: addresss comments from PR review
witgaw Oct 1, 2024
a5db16b
refactor: fix spellcheck
witgaw Oct 1, 2024
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
36 changes: 34 additions & 2 deletions protocol/0090-VAMM-automated_market_maker.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -65,7 +65,7 @@ The `Concentrated Liquidity` AMM is a market maker utilising a Uniswap v3-style

The concentrated liquidity market maker consists of two liquidity curves of prices joined at a given `base price`, an `upper` consisting of the prices above this price point and a `lower` for prices below it. At prices below the `base price` the market maker will be in a long position, and at prices above this `base price` the market maker will be in a short position. This is configured through a number of parameters:

- **Base Price**: The base price is the central price for the market maker. When trading at this level the market maker will have a position of `0`. Volumes for prices above this level will be taken from the `upper` curve and volumes for prices below will be taken from the `lower` curve.
- **Base Price**: The base price is the central price for the market maker. When trading at this level the market maker will have a position of `0`. Volumes for prices above this level will be taken from the `upper` curve and volumes for prices below will be taken from the `lower` curve. This price can be either user supplied or set (and maintained with an oracle). Please see [oracle-driven base price](#oracle-driven-base-price) section for more detail on the later case.
- **Upper Price**: The maximum price bound for market making. Prices between the `base price` and this price will have volume placed, with no orders above this price. This is optional and if not supplied no volume will be placed above `base price`. At these prices the market maker will always be short
- **Lower Price**: The minimum price bound for market making. Prices between the `base price` and this will have volume placed, with no orders below this price. This is optional and if not supplied no volume will be placed below `base price`. At these prices the market maker will always be long
- **Commitment**: This is the initial volume of funds to transfer into the sub account for use in market making. If this amount is not currently available in the main account's general account the transaction will fail.
Expand Down Expand Up @@ -98,7 +98,7 @@ A `Concentrated Liquidity` AMM has an inherent linkage between position and impl
- Enter a limit order to sell `5` contracts for `7 USDT` into the order book and allow it to match.
1. If a price level is reached such that the current price is more than the max slippage specified away from the best bid, reject the transaction.
1. If there is no upper range specified, it is marked as created immediately.
1. If the AMM's `base price` is above the current `best ask` and the AMM has a lower range specified, then the vAMM would need to become short in order to synchronise with the market. Follow an identical process as above but instead on increasing price levels from `best ask`
1. If the AMM's `base price` is above the current `best ask` and the AMM has a lower range specified, then the vAMM would need to become long in order to synchronise with the market. Follow an identical process as above but instead on increasing price levels from `best ask`
1. If there is no lower range specified, it is marked as created immediately.

#### Amendment
Expand Down Expand Up @@ -127,6 +127,26 @@ In addition to amending to reduce the size a user may also cancel their AMM enti

Note that, whilst an `Abandon Position` transaction immediately closes the AMM a `Reduce-Only` transaction will keep it active for an uncertain amount of time into the future. During this time, any Amendment transactions received should move the AMM out of `Reduce-Only` mode and back into standard continuous operation.

### Oracle-driven base price

The base price can either be a fixed scalar specified by a user or a dynamic value supplied from one of the oracles already setup for the market. It should be possible to switch between the two with a regular vAMM amendment transaction.

When oracle-driven base price is selected during the vAMM creation then the system first awaits the receipt of the next data point from the oracle and then follows the process outlined in [creation/amendment process](#creationamendment-process) with `base price` set to that value.
Copy link
Contributor

@wwestgarth wwestgarth Sep 26, 2024 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe a word on what to do about slippage? When you submit an AMM the transaction comes with a slippage field that controls how far to allow the AMM's fair-price can move from its base-price when it tries to "rebase" the AMM so that it doesn't cross with whats already on the book. An amend transaction has one too which works the same but between the amended AMM's current fair price and where it would now need to be to not cross.

Do we want something similar here too? For example if the oracle-drive price suddently is wildly different from where the AMM is currently at should we have some sort of protection? Or should it always try to rebase itself even if it means eat up a lot of volume to get there?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should use the slippage specified when the vAMM was first set up, if this is an amendment that specifies slippage then the new slippage should be used.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Modified the spec to use the slippage


Similarly, when the vAMM configuration is amended to use the oracle-driven base price rather than a fixed user supplied value, the system awaits the receipt of the next data point from the oracle and then uses that value as the `base price` in the regular amendment transaction outlined above. Please note that **configuration amendment** from a fixed to oracle-driven base price should only be rejected if the oracle specification is incorrect. If the `base price` received from the oracle is such that the **value amendment** is rejected then the value should remain unchanged, but the next **value amendment** should still be attempted the next time around.

#### Minimum price change trigger

An optional non-negative parameter `m` controlling the minimum price change (current `base pase` price the vAMM is using vs value arriving from the oracle) should be included in the oracle-driven base price configuration. When set to `0` the `base price` will update each time a new value is received from the oracle. When set to a positive value, the `base price` should only be amended if `abs(base price / new price - 1) >= m`. The default value of this parameter should be `0`.

#### Slippage

When the new value arriving from the oracle satisfies the [minimum price change trigger](#minimum-price-change-trigger) and the change in `base price` will result in a trade, the slippage of the rebasing trade should be considered - if it violates the maximum slippage setup for the vAMM then the base price should remain unchanged. The next time a value is received from the oracle the process should be carried out again. If the amendment transaction also contains a new value for the maximum slippage then it's this new value that should be used to determine if the rebasing trade should go ahead or not.

#### Bounds

When the `base price` is updated as a result of receiving a new value from the specified oracle the bounds should remain unchanged.

### Determining Volumes and Prices

Although AMM prices are not placed onto the book as orders it is necessary to be able to be able to quote prices for a given volume, or know what trading volume would move the fair price to a certain level.
Expand Down Expand Up @@ -341,3 +361,15 @@ At market settlement, an AMM's position will be settled alongside all others as
- With an existing book consisting solely of vAMM orders, pegged orders referencing best bid/best ask remain deployed, pegged to their pegs, where the best buy/sell vAMM order price acts as the best bid, or best ask peg respectively. (<a name="0090-VAMM-036" href="#0090-VAMM-036">0090-VAMM-036</a>)

- With an existing book consisting solely of vAMM orders on one side, pegged orders referencing best bid/best ask remain deployed on the side with the vAMM orders. Pegged orders referencing the empty side of the book are parked. (<a name="0090-VAMM-037" href="#0090-VAMM-037">0090-VAMM-037</a>)

- It's possible to setup the vAMM so that it uses one of the oracles already available for the market in which it operates for its `base price`. In that case the deployment attempt should be deferred until the next value is received from the oracle. (<a name="0090-VAMM-038" href="#0090-VAMM-038">0090-VAMM-038</a>)

- It's possible to amend the vAMM with a fixed `base price` so that it uses one of the oracles already available for the market in which it operates for its `base price`. The actual change of base price should only happen once the next value is received. (<a name="0090-VAMM-039" href="#0090-VAMM-039">0090-VAMM-039</a>)

- When vAMM uses oracle for the base price, and the relative difference between the new and existing `base price` is less than `minimum price change trigger` then base price doesn't get updated. The update only happens once a value received from the oracle is more than `minimum price change trigger`. (<a name="0090-VAMM-040" href="#0090-VAMM-040">0090-VAMM-040</a>)

- When vAMM uses oracle for the base price, and the relative difference between the new and existing `base price` is more than `minimum price change trigger` as well as the slippage of the rebasing trade is within the maximum slippage setup for the vAMM the `base price` is updated when the new value is received from the oracle. (<a name="0090-VAMM-041" href="#0090-VAMM-041">0090-VAMM-041</a>)

- When vAMM uses oracle for the base price, and the relative difference between the new and existing `base price` is equal to `minimum price change trigger` but the slippage of the rebasing trade is more than the maximum slippage setup for the vAMM the `base price` doesn't get updated. If when the next value arrives and all the conditions are satisfied then that's when the `base price` gets updated. (<a name="0090-VAMM-042" href="#0090-VAMM-042">0090-VAMM-042</a>)

- If the vAMM amendment contains both the new `maximum slippage` and a transaction to change the `base price` from a fixed value to the oracle-driven one, then the `maximum slippage` gets updated immediately and it's that new value that gets considered in all the subsequent amendments triggered by the receipt of the new `base price` from the oracle. (<a name="0090-VAMM-043" href="#0090-VAMM-043">0090-VAMM-043</a>)
10 changes: 8 additions & 2 deletions protocol/features.json
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -772,7 +772,13 @@
"0016-PFUT-031",
"0074-BTCH-024",
"0074-BTCH-025",
"0074-BTCH-026"
"0074-BTCH-026",
"0090-VAMM-038",
"0090-VAMM-039",
"0090-VAMM-040",
"0090-VAMM-041",
"0090-VAMM-042",
"0090-VAMM-043"
]
},
"LP 3.0": {
Expand Down Expand Up @@ -903,7 +909,7 @@
]
},
"Program enactment fixes": {
"milestone": "genbutemple",
"milestone": "genbutemple",
"acs": [
"0083-RFPR-056",
"0083-RFPR-057",
Expand Down
Loading