Bucket Claiming

Dive into the claimFromAggregated() function and further considerations

There is a bit of nuance to the claimFromAggregated() function which users need to take note of.

For example, claiming proceeds using this function is most viable when a LP has not changed their position during a given bucket interval. If a LP has changed their position over a given range, they will need to do multiple claiming transactions, with each being over a loan range for which their given pro-rata pool shares were constant and untouched. Thus, if a LP wants to make use of the claimFromAggregated() function, they can only do this if they were invested for the whole bucket they’re trying to claim from, and if they maintained a constant pool share position throughout the whole bucket.

To use the protocol efficiently, LPs must actively claim any loan proceeds. As an active LP, claiming individual loans can come with significant transactional overhead and gas costs, especially if you are trying to claim proceeds from a larger number of loans. The built-in aggregation mechanism helps make claiming more efficient, but it cannot be guaranteed that LPs will be able to take advantage of the full aggregation benefits. This is because the eligibility to claim from buckets depends on the time that the LP added liquidity. For example, if the LP added at loan index 100 and remains invested until loan index 200, they’ll be able to claim from the full range from loan index 100 to 200. However, if they add liquidity at loan index 101, they’ll have to claim individually by iterating over 99 loans, making claiming more costly.