What happens if a position is queued up and for whatever reason not updated with a price point?

[mesozoic-technology]

Because we need to lock positions in at time t+1, there is some possibility that someone queues up a position and then it is not activated/updated - not given a price.

How should we solve for this?

Partially this depends on the oracle we use. If we use an oracle that can see into the past, then we can be more lenient here and allow the update function to loop backwards through all unset positions.

Probably in any case however, we would want to make a worse case scenario for a position. If for whatever reason this happens, users should be able to get their money back without difficulties.

This has implications for how we manage the queued OI, and what else?

[mikeyrf]

Yea agreed here. Was thinking of using Keeper Network as a backup to hit the update function - although less frequently than updatePeriod.

Probably a better solution would be to have a maxSlippage parameter inputted to the build() function, so user's can withdraw their OVL funds if their lock price slips more than expected. Ideally, the tx would revert here, but don't think that's possible in the T+1 setup.

[mesozoic-technology]

Hmm interesting on the maxSlippage, I'm not sure how that would work. There can be many people in one position.

[mikeyrf]

Ah fair point. The fungibility of the position shares kind of kills this.

The other option is to let people cancel/unwind their build before settlement at T+1

[mesozoic-technology]

slippage discussions to -> #4

[mikeyrf]

A similar point to think about:

In the current architecture, it is assumed that the market contract can fetch from the oracle regularly at each update interval.

Are there problems around this? For example: what happens if in times of stress the oracle we are fetching from is not able to update its value on-chain, but the off-chain value is known to have changed substantially? Our market contracts wouldn't know this