Oracle-driven base price for vAMMs #2375
Conversation
There was a problem hiding this comment.
One really nit-picky comment, the real review will have to come from William @wwestgarth anyway.
|
|
||
| #### Maximum update frequency | ||
|
|
||
| An optional non-negative parameter controlling the maximum update frequency 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 be amended to the last value received from the oracle once the specified time elapses. If such value is the same as the currently specified `base price` then there should be no effect. The default value of this parameter should be `0`. |
There was a problem hiding this comment.
This is a bit confusing, we have 'frequency' but then say the update happens after a time interval elapses. Should we call it "Maximum update time interval"?
There was a problem hiding this comment.
Maybe I'm missing something, but I don't think we even need this field since I think it can be handled solely by the existing data source framework we have.
For example if we set it up an Ethereum contract call to drive the base price, there is already a field in the data-source definition for "how frequently to read the contract". And if you are sending in new prices by hand using a normal trusted-key oracle-submission-transaction then you'll just only send it in when you want it updated anyway.
There was a problem hiding this comment.
Would it be better to have % change of how far out the base price is from the oracle input?
That's to avoid paying taker fees when changes to base price would result in trades for the vAMM.
There was a problem hiding this comment.
Modified the spec to use the relative price change.
|
|
||
| The base price can either be a fixed scalar specified by a user or an [oracle configuration](./0045-DSRC-data_sourcing.md). 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. |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
Modified the spec to use the slippage
| @@ -127,6 +127,18 @@ 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 an [oracle configuration](./0045-DSRC-data_sourcing.md). It should be possible to switch between the two with a regular vAMM amendment transaction. | |||
There was a problem hiding this comment.
I guess its implied, but I'm assuming when a new oracle price comes in to change the base price, the lower and upper boundary prices are also changed by the same delta?
There was a problem hiding this comment.
First iteration: unless we hear strongly that someone needs the bunds to move as well, let's keep these fixed.
There was a problem hiding this comment.
@wwestgarth is one of them much cleaner than the other from implementation point of view?
There was a problem hiding this comment.
It doesn't make any difference to the implementation really, so its mostly what would be most useful to people.
There was a problem hiding this comment.
Went with fixed bounds for now, let's give people the option to either leave them fixed or updated them proportionally once they ask for it.
Closes #2367