Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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
Osmosis price oracle #155
Osmosis price oracle #155
Changes from 11 commits
017f2ad
76f1dd0
b8a3abd
67f569b
e2c7078
653418f
de1dd23
736e4f8
3bf001b
b27aa9b
bac07f7
82f5c1e
14dfe9b
36841f2
1dfb124
3f5759f
ead36e4
112693b
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
Large diffs are not rendered by default.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Makes sense. Setting a TTL that is slightly larger than the epoch will help with handling delays in the price update process.
Perhaps all this can be derived from a single parameter. Including the IBC timeout as well. But, let's leave that for another iteration.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does this mean 'never'? You can as well save the current block time here.
I think this is better, as it would schedule a price update at the first en block handler call after instantiation, right?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No, this is the time of the last update.
0
stands for year 1970 and is pretty much guaranteed to mean "out of date", so that an update is scheduled after instantiation. If we change it to "now", the next update will be atnow + epoch_in_secs
, so it might introduce an unnecessary lag if anything.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
TBH if instead of using "end block" we can configure an interval in the native Cosmos module, this whole "epoch length" dance becomes unnecessary here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, but it doesn't hurt either, and allows for different contracts to have different update periods while using the same SDK.
It's also slightly more robust.