-
Notifications
You must be signed in to change notification settings - Fork 17
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
Conversation
2585e06
to
305ee37
Compare
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.
Initial review of the price provider. Will take a look at the consumer next.
serde = { workspace = true } | ||
sylvia = { workspace = true } | ||
thiserror = { workspace = true } | ||
osmosis-std = "0.20.1" |
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.
👍🏼
packages/apis/src/ibc/packet.rs
Outdated
#[cw_serde] | ||
pub enum PriceFeedProviderPacket { | ||
Update { twap: Decimal }, | ||
} |
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.
Good start. Some ideas / suggestions:
- Listing the token pair the price is for, for robustness.
- Adding a timestamp.
- Adding a source / origin. It can be just a description. Good for logging / tracking.
Hey @maurolacy! I appreciate the review, but there's no need to go so in-depth when this is still a draft, pending a cleanup. I feel like the energy is better spent taking a high level view and verifying if this is what we want. I'll address the comments on Monday. Till then! |
Thanks for the pointer. Put some comments there as well. |
18e9c34
to
e21e090
Compare
Codecov ReportAttention:
❗ Your organization needs to install the Codecov GitHub app to enable full functionality. Additional details and impacted files@@ Coverage Diff @@
## main #155 +/- ##
==========================================
- Coverage 88.40% 87.18% -1.22%
==========================================
Files 69 80 +11
Lines 13151 14264 +1113
Branches 13151 14264 +1113
==========================================
+ Hits 11626 12436 +810
- Misses 992 1310 +318
+ Partials 533 518 -15 ☔ View full report in Codecov by Sentry. |
Alright, I won't stall more. I'll try to add some tests in a separate PR for what I can, although there's very little non-IBC logic here. |
Co-authored-by: Mauro Lacy <[email protected]>
c45ac2c
to
bac07f7
Compare
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.
Pretty good. Looking forward to some tests, and we can merge.
Decimal::from_str( | ||
&querier | ||
.arithmetic_twap_to_now(pool_id, base.into(), quote.into(), None)? | ||
.arithmetic_twap, | ||
) |
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.
Looks good. Let's confirm this with the Osmosis team at some point, and adjust if needed.
self.last_epoch | ||
.save(ctx.deps.storage, &Timestamp::from_seconds(0))?; |
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 at now + 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.
pub epoch_in_secs: Item<'static, u64>, | ||
pub price_info_ttl_in_secs: Item<'static, u64>, |
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.
f2367a2
to
3f5759f
Compare
Maybe closes #99
sdk.Dec
gotten fromarithmetic_twap_to_now
is stringified