-
Notifications
You must be signed in to change notification settings - Fork 5
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
edits_feb5 #15
edits_feb5 #15
Changes from 6 commits
15d272f
8ccd3ce
8723a1c
edbf7f6
335682d
1b562ec
559e153
e181a32
5c5b21d
7b2b62b
7a97205
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -333,7 +333,9 @@ pub async fn run_verification_loop(store: Arc<Store>) { | |
while !SHOULD_EXIT.load(Ordering::Acquire) { | ||
let all_opportunities = store.liquidation_store.opportunities.read().await.clone(); | ||
for (permission_key, opportunity) in all_opportunities.iter() { | ||
match verify_with_store(opportunity.clone(), &store).await { | ||
// just need to check the most recent opportunity, if that fails the rest should also be removed | ||
// TODO: this is true for subsequent opportunities that only have updated price updates, but may not be true generally; we should think about how best to do this (one option is to just check every single saved opportunity and remove from the store one by one) | ||
match verify_with_store(opportunity[0].clone(), &store).await { | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I don't see why we can't verify each and every one of them here? and remove with the same logic. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. mostly concern around efficiency, and for opportunities where the only change is newer price updates that still maintain undercollateralization, invalidity of opp with price_update_t should imply invalidity of opp with price_update_s for s <= t. but in general when subsequent opportunities have other changes or it's not just using pyth price feeds as TokenVault is, there may be some other dependencies and behavior (e.g. if protocol wants to use pyth price feeds with a more strict latency requirement than enforced by Pyth where it fails if using a stale price). for now will make the change to verifying each one, and we can revert later if efficiency is an issue |
||
Ok(_) => {} | ||
Err(e) => { | ||
store | ||
|
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.
why are you only checking with the first one and not all?
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.
Mostly because the number of checks could grow out of proportion. If there are ~2.5 price updates per second and an opportunity sticks around for a while, the size of that vector could grow and explode the number of checks here.
And I think for the most part the main check we want is to ensure that the same exact opportunity isn't submitted twice in a row. If protocol is using the most recent price update, that should not revert to a historical price update, so we should be fine as long as we check the top opportunity in the stack