In the current state, we can't apply pool-specific guardrails for big unbalanced liquidity operations at the pool level for computeInvariant. BasePoolMath just computes the invariant several times and solves the result, but unless we apply system-wide constraints there's no way to get pool-specific constraints unless we add a new getter to the pools.
An alternative approach is to write the computations in BasePoolMath in terms of the ratio, allowing pools to implement their own constraints.
WIP for now; tests are not passing yet.
Type of change
[ ] Bug fix
[ ] New feature
[ ] Breaking change
[ ] Dependency changes
[ ] Code refactor / cleanup
[ ] Optimization: [ ] gas / [ ] bytecode
[ ] Documentation or wording changes
[ ] Other
Checklist:
[ ] The diff is legible and has no extraneous changes
[ ] Complex code has been commented, including external interfaces
[ ] Tests have 100% code coverage
[ ] The base branch is either main, or there's a description of how to merge
Description
In the current state, we can't apply pool-specific guardrails for big unbalanced liquidity operations at the pool level for
computeInvariant
.BasePoolMath
just computes the invariant several times and solves the result, but unless we apply system-wide constraints there's no way to get pool-specific constraints unless we add a new getter to the pools.An alternative approach is to write the computations in
BasePoolMath
in terms of the ratio, allowing pools to implement their own constraints.WIP for now; tests are not passing yet.
Type of change
Checklist:
main
, or there's a description of how to mergeIssue Resolution