Add optimal time and accrued amount math derivation to the whitepaper

[bingen]

From @danielattilasimon on Slack:

Stumbled upon an interesting property of the ChickenBonds accrual function while doing calculations for the game. Let’s define the familiar accrual function as gamma(t) = t / (t + alpha). Thus, the claimable bTKN is (P * (1 - tau) / p_r) * gamma(t), where P is the principal, p_r the redemption price and tau the chicken-in fee. Let gamma_opt := gamma(t_opt), t_opt being the time of optimal chicken-in. For simplicity, it shall be based on maximal APR (and also because that’s what’s communicated on the frontend). Thanks to @bingen , we know that t_opt = alpha * (1 + sqrt((1 - tau) * lambda)) / ((1 - tau) * lambda - 1) where lambda is the market price divided by the redemption price. Let’s extract beta := (1 + sqrt((1 - tau) * lambda)) / ((1 - tau) * lambda - 1). Thus:

gamma_opt = gamma(t_opt)
= gamma(alpha * beta)
= alpha * beta / (alpha * beta + alpha)
= beta / (beta + 1)

We get that the optimal accrual factor does not directly depend on alpha (the accrual parameter). If we substitute beta back into gamma_opt and simplify, we get: gamma_opt = 1 / sqrt((1 - tau) * lambda) Here’s a real life example (see screenshot demonstrating agreement by the UI — the match isn’t perfect because market price and redemption price on the UI aren’t precise enough): (P * (1 - tau) / p_r) * gamma_opt = (1250 * 0.9 / 1.01) / sqrt(0.9 * 1.55 / 1.01)) = 947.8 bLUSD

I quite like this because it means that reducing alpha via the controller (and thus speeding up accrual) doesn’t directly change the fraction of principal that goes into the permanent bucket. Of course in reality the faster accrual will probably have an effect on the market price (and thus lambda too) eventually, which will change the optimal accrual factor.

[bingen]

Also from Slack:

Following up on this, the last value for optimal accrued amount can be expressed as: P * sqrt((1-tau)/(p_f*p_r))