Issue 159 add position caps #174
Conversation
markuspluna
changed the base branch from
main
to
issue_160_test_auction_underflow
There was a problem hiding this comment.
It's also worth considering if we want to add logic to protect users while reducing their overall postion size.
Consider - max positions (4) user positions (4)
Pool updates the max positions to (2) to fix a stuck liquidation or something
user goes to repay a borrowed asset (or user positions is staged for liquidation?), and they can't. Worse off, they could be withdrawing a dust position?
pool/src/storage.rs
Outdated
| // Fetch the current max posoitions | ||
| /// |
pool/src/storage.rs
Outdated
| /// Set a new admin | ||
| /// | ||
| /// ### Arguments | ||
| /// * `max_positions` - The max positions for the pool |
pool/src/contract.rs
Outdated
| fn set_max_positions(e: Env, max: u32) { | ||
| storage::extend_instance(&e); | ||
| let admin = storage::get_admin(&e); | ||
| admin.require_auth(); | ||
|
|
||
| storage::set_max_positions(&e, &max); | ||
|
|
||
| e.events() | ||
| .publish((Symbol::new(&e, "set_max_positions"), admin), max); | ||
| } |
There was a problem hiding this comment.
this should likely be included with pool_init_meta, right? Like backstopTakeRate, it feels like a vital piece of setup required for the pool to function and should be set on initialization.
In the same vein, it feels appropriate to include this with update_pool or rename that function to set_backstop_rate to avoid confusion.
Having one function that sets multiple pieces of pool configuration doesn't seem problematic to me, but I don't have a strong opinion either way.
pool/src/pool/actions.rs
Outdated
| // Verify max positions haven't been exceeded | ||
| pool.require_under_max(e, from_state.positions.clone(), request.request_type) |
There was a problem hiding this comment.
We can likely get away with only checking this after all requests have been processed.
We know how many positions they started with, so if it increases, just need to make sure its at most the maximum.
In accordance with issue 159 added a max_positions variable that is controllable by the pool admin. This allows pool admins to prevent user's from opening too many positions resulting in resource limits being exceeded when someone attempts to liquidate them.