Pool metrics are wrong / weird

[kappacappa]

Pool performance metrics are incorrect or nonsensical numbers.

---

Bounty

• This issue has a bounty of $50, paid in crypto.
• Bounties are paid upon full resolution of the issue with high quality code, within a reasonable timeframe.
• Important: To be eligible for the bounty, comment below to request assignment to this issue.

[ModernForays]

I'll take a look at this issue.

[kappacappa]

@ModernForays assigned.

[ModernForays]

Some thoughts on how to calculate these one week/one month/one year performance stats. We cannot calculate this exactly from periodic aggregations because deposits, withdrawals, and trades happen in arbitrary order within a period, and deposits/withdrawals have the effect of diluting/concentrating returns to poolers, so order matters. It is entirely possible that 100 people joining the pool in a given period could have from 1 to 100 different rates of return they achieve during the period, so what we want is an estimate that "sounds right" to as many of the 100 people as possible when they check their own balance. There are several ways we could model the timing of deposits and withdrawals within a single period: as happening at the beginning of the period, as happening at the end of the period, as happening uniformly throughout the period, etc.

Starting from the beginning, the relation between the starting and ending balances are:

Ending_Balance = Starting_Balance + Income + Deposits - Withdrawals

Rearranging this for income:

Income = Ending_Balance + Withdrawals - Starting_Balance - Deposits

We can calculate the income exactly from the periodic aggregations. The need to estimate arises from how the income should be attributed to poolers without access to intra-period deposit/withdrawal/trade data. If we assume that all deposits and withdrawals happen at the end of the period, the rate of return for a single period is:

Income / Starting_Balance

If we assume all deposits and withdrawals happen at the start of the period, the rate of return for a single period is:

Income / (Starting_Balance + Deposits - Withdrawals)

We could also imagine treating deposits as occurring at the start of a period and withdrawals as occurring at the end, or vice versa. When the rate of return is positive during a given period, the most pessimistic estimate of returns would treat deposits as occurring at the beginning of the period (diluting gains maximally), and withdrawals as happening at the end of the period. Similarly, the most optimistic return estimate would treat withdrawals as happening at the beginning of the period (concentrating gains maximally) and deposits as happening at the end of the period. Conversely, when rate of return is negative, deposits at the beginning with withdrawals at the end yield the most optimistic return estimate (diluting losses maximally) and withdrawals at the beginning with deposits at the end yields the most pessimistic (concentrating losses maximally). The pessimistic estimates give us approximately "what would your performance as a long term LP look like if deposits/withdrawals were perfect JITs with a duration of one period," and the optimistic estimate gives us approximately "what would your performance as a long term LP look like if deposits/withdrawals were completely failed JITs lasting one period."

We could also imagine averaging Starting_Balance and Starting_Balance + Deposits - Withdrawals to get a midpoint value for the denominator of our rate of return. I think this has the attractive property of treating Depositors/Withdrawers as JIT'ers who are neither particularly good nor particularly bad at JITing, which seems reasonable.

---

Once we have settled on a reasonable way of modeling returns for a single period, the next question is how to model returns across several periods. The intent of the code today is to treat all of the individual periods as single larger period, summing the deposits and withdrawals from the individual periods to calculate the period's income as Ending_Balance[last_period] + Sum(Withdrawals) - Sum(Deposits) - Starting_Balance[first_period], treating e.g. seven days as one big day where seven days' worth of activity happened. This will give us a fine estimate, but it might also be nice to estimate returns for each of the component periods and then calculate the total performance by compounding across the individual periods because we know for instance that net deposits on day zero will be subject to six days of growth or loss, net deposits on day one to five days, etc.

[kappacappa]

@ModernForays indeed pool performance is not meant to be completely exact but give an idea of expected returns. It is calculated similarly to how a fund would display historical returns, e.g. ending balance - starting balance, net of inflows (deposits) and outflows (withdrawals).

Keeping in mind that deposits and withdrawals simply track the LP deposits and withdrawals, not pay ins or pay outs from / to traders. Those are implicitly included in the pool balance.

I'm fine with doing something like this

We could also imagine averaging Starting_Balance and Starting_Balance + Deposits - Withdrawals to get a midpoint value for the denominator of our rate of return. I think this has the attractive property of treating Depositors/Withdrawers as JIT'ers who are neither particularly good nor particularly bad at JITing, which seems reasonable.

to get a return possibly closer to a client expectation. Not sure how much better of a return model it would be for clients, so we'd have to weigh complexity of that vs keeping what we already have.

[ModernForays]

I'm fine with doing something like this

We could also imagine averaging Starting_Balance and Starting_Balance + Deposits - Withdrawals to get a midpoint value for the denominator of our rate of return. I think this has the attractive property of treating Depositors/Withdrawers as JIT'ers who are neither particularly good nor particularly bad at JITing, which seems reasonable.

to get a return possibly closer to a client expectation. Not sure how much better of a return model it would be for clients, so we'd have to weigh complexity of that vs keeping what we already have.

Cool. If you want to take a look, #58 implements this but I'm holding off on testing until pool-stats API endpoint is returning correct data.

[autochamchikim-pixel]

I submitted a focused PR for this bounty and would like to request assignment per the issue instructions: #148

[JeremyZeng77]

Hi, I opened a PR for this bounty and would like to request assignment/consideration: #158

The patch applies the midpoint capital model discussed above and also scopes deposits/withdrawals to the selected performance window.

Payout preference if accepted: USDT TRC20 TWupTAoFjxR2VmqUUvzhfmUwXVZR6Kvz1Y, or PayPal fallback https://paypal.me/Jeremytsangchina.

[zp6]

Claiming this bounty! Wallet: zp6

[JeremyZeng77]

Submitted a fix PR for this bounty:

• PR: fix: correct pool performance window aggregation (issue #6) #219

What was fixed:

• performance now aggregates deposits/withdrawals only within the selected window (1W/1M/1Y)
• per-asset window indices are normalized independently (no cross-asset index mutation)

Verification:

• npm run build passed locally

Payout:

• PayPal: https://paypal.me/Jeremytsangchina
• USDT (TRC20): TWupTAoFjxR2VmqUUvzhfmUwXVZR6Kvz1Y