fix(across): address issue in liquidity utilization calculation #3499
Conversation
Signed-off-by: Christopher Maree <christopher.maree@gmail.com>
…ttps://github.com/UMAprotocol/protocol into chrismaree/fix-implementation-liquidityutilization
Co-authored-by: nicholaspai <9457025+nicholaspai@users.noreply.github.com>
Signed-off-by: Christopher Maree <christopher.maree@gmail.com>
…github.com:UMAprotocol/protocol into chrismaree/fix-implementation-liquidityutilization
| _sync(); // Fetch any balance changes due to token bridging finalization and factor them in. | ||
|
|
||
| // liquidityUtilizationRatio := | ||
| // (relayedAmount + pendingReserves + max(utilizedReserves,0)) / (liquidReserves + max(utilizedReserves,0)) |
There was a problem hiding this comment.
One side effect of flooring utilizedReserves when it is negative (due to having tokens transferred to the contract by mistake) is that the calculated utilization rate would drop just after the pending relay is settled since the settlement moves deposit amount from pendingReserves to utilizedReserves.
Maybe alternative to avoid this could be to floor the sum of (pendingReserves + utilizedReserves)? Though not sure if this still is ideal, but the source of the problem is not being able to distinguish token transfers by mistake from L2->L1 native bridging transfers.
There was a problem hiding this comment.
ye, this is a good idea! I think we'll leave as it is for now and can re-visit this in the coming week and make sure that we are all happy with how this is implemented right now.
chrismaree
deleted the
chrismaree/fix-implementation-liquidityutilization
branch
Motivation
This PR addresses a small issue in the
liquidityUtilizationPostRelaywhich did not correctly consider the denominator. The denominator now considersutilizedReservesto correctly capture the funds in the pool.Testing
Check a box to describe how you tested these changes and list the steps for reviewers to test.