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

poke once a day, use struct, more changes #4

Draft
wants to merge 13 commits into
base: sticky
Choose a base branch
from

Conversation

oldchili
Copy link
Contributor

@oldchili oldchili commented Dec 5, 2023

No description provided.

src/StickyOracle.sol Outdated Show resolved Hide resolved
uint32 public age; // time of last poke
struct Accumulator {
uint256 val;
uint32 ts;
Copy link
Contributor

Choose a reason for hiding this comment

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

I'm not sure tracking the exact poke ts is worth the added poke cost (vs just using the eod ts). Generally if we expect the window to be much larger than 1 day (e.g. 30 days) the gain in precision is likely to be negligible (I did some quick approximation math to convince myself of it but might be good to test with actual values).

Copy link
Contributor Author

@oldchili oldchili Dec 5, 2023

Choose a reason for hiding this comment

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

Well the poke is only done once a day, so even if it's a matter of a few storage operations (probably less) I think it's negligible.
I think storing the timestamps is the more simple and standard way (for example Uniswap have this Observation struct - https://github.com/Uniswap/v2-periphery/blob/master/contracts/examples/ExampleSlidingWindowOracle.sol#L19).

Copy link
Contributor

Choose a reason for hiding this comment

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

Ok, though note that in the Uniswap example the timestamp is necessary as the accumulators are not indexed by days. That said I don't mind storing the ts here given the frequency of poke calls. I guess we don't need it to be packed as a uint32 though, uint256 would work fine and save a tiny bit of gas.

src/StickyOracle.sol Outdated Show resolved Hide resolved
src/StickyOracle.sol Outdated Show resolved Hide resolved
src/StickyOracle.sol Outdated Show resolved Hide resolved
// days_ == N will fill up a window corresponding to [lo == N, hi == 1] along with the current day
// days_ should be selected carefully as too many iterations can cause the transaction to run out of gas
// if the initiated timespan is shorter than the [lo, hi] window the initial cap will just be used for longer
function init(uint256 days_) external auth returns(bool) {
Copy link
Contributor

Choose a reason for hiding this comment

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

Suggested change
function init(uint256 days_) external auth returns(bool) {
function init(uint256 days_) external auth returns (bool) {

@@ -17,29 +17,39 @@
pragma solidity ^0.8.16;

interface PipLike {
function read() external view returns (uint128);
function peek() external view returns (uint128, bool);
function read() external view returns (uint128); // TODO: shouldn't this (and our function) return bytes32? https://github.com/makerdao/osm/blob/e36c874b4e14fba860e48c0cf99cd600c0c59efa/src/osm.sol#L150C49-L150C56
Copy link
Contributor

Choose a reason for hiding this comment

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

The main reason for using a uint128 type was to be able to pack val and age in the same slot (and avoid an explicit cast for a value which under the hood is anyway a uint128 in the pip/osm). But since these variables have been removed, feel free to use a bytes32 (like in the osm) or a uint256 (like in the pip).

uint96 public slope = uint96(RAY); // maximum allowable price growth factor from center of TWAP window to now (in RAY such that slope = (1 + {max growth rate}) * RAY)
uint8 public lo; // how many days ago should the TWAP window start (exclusive)
uint8 public hi; // how many days ago should the TWAP window end (inclusive)
uint96 public slope = uint96(RAY); // maximum allowable price growth factor from the average value of a TWAP window (in RAY such that slope = (1 + {max growth rate}) * RAY)
Copy link
Contributor

Choose a reason for hiding this comment

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

What I was trying to say here is that, given that the TWAP is an unbiased smoothed estimate of the price at the time in the middle of the TWAP window, the slope can be interpreted as the allowable growth between that particular time and now. But maybe it's simpler to just describe it as a TWAP multiplier.

Suggested change
uint96 public slope = uint96(RAY); // maximum allowable price growth factor from the average value of a TWAP window (in RAY such that slope = (1 + {max growth rate}) * RAY)
uint96 public slope = uint96(RAY); // maximum allowable price growth factor in reference to the TWAP (in RAY such that slope = (1 + {max growth rate}) * RAY)

Copy link
Collaborator

Choose a reason for hiding this comment

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

Ahh ok got it. Although I think it is easier to describe it as the multiplier of the TWAP.
Your correction looks good to me.

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 this pull request may close these issues.

3 participants