estimate tco2 redemption amount given pool redemption amount

[PawelTroka]

fixes #38
simulator can be found here: https://colab.research.google.com/drive/1v66a-_ez8foIbsIsg7cwRj3Et-bapU2r#scrollTo=EPhXZrXW1BDS&line=73&uniqifier=1

[kosecki123]

Some extra info on gas usage:

estimateTCO2RedemptionAmount gas usage depends on the max iterations amount

Higher the amount = better estimate, still even with 10 iterations we are below 1% error

40 iterations = 1267785
20 iterations = 650471
10 iterations = 341823

If we use this as view calls from outside, we should keep 40. If we want to anyways put this into redeem transaction we should go with 10 or lower.

All gas usages taken by using:

forge test --via-ir -vvvv --match-test testEstimateTCO2RedemptionAmount_NormalCase_ShouldGiveResultsWithSmallSlippage --gas-report

[kosecki123]

lgtm, lets's wait for @0xmichalis

[0xmichalis]

Unfortunately I am not too strong on math but I'd expect this to be implemented with the use of the inverse of the current function that estimates fees so we don't have to approximate a response. Is that wishful thinking? :) cc @aspiers

[PawelTroka]

Unfortunately I am not too strong on math but I'd expect this to be implemented with the use of the inverse of the current function that estimates fees so we don't have to approximate a response. Is that wishful thinking? :) cc @aspiers

I am not sure if that is possible given we have implicit function there
redemptionAmount = poolAmount - calculateRedemptionFee(redemptionAmount, current, total)

[0xmichalis]

I am not sure if that is possible given we have implicit function there
redemptionAmount = poolAmount - calculateRedemptionFee(redemptionAmount, current, total)

Hrm, I think you are right. Somehow I thought the inverse of the current curve would be useful but it doesn't make much sense on a second thought.

[aspiers]

It's not an inverse function exactly. I have taken a stab at documenting here:

https://www.notion.so/toucan-protocol/Redemption-with-CHAR-spend-as-input-c88f4c4c6c7a4b1b814d8ce20681bf31

but I probably made mistakes. Can we use something more efficient than linear bisection, like Newton's method?

[PawelTroka]

It's not an inverse function exactly. I have taken a stab at documenting here:

https://www.notion.so/toucan-protocol/Redemption-with-CHAR-spend-as-input-c88f4c4c6c7a4b1b814d8ce20681bf31

but I probably made mistakes. Can we use something more efficient than linear bisection, like Newton's method?

Unfortunately I do not seem to have access to this notion page :(

To be totally honest I am not 100% sold on Newton's method as there is a small risk that it may not converge in all cases. Also a derivative for our getRedemptionFee might not be so trivial, we could use finite difference which brings us to secant method but this is no longer so superior to what we have right now while being slightly more complicated. I don't have strong opinions here but I think what we have right now is okayish for the time we spent on it.

[aspiers]

@PawelTroka I gave you access to the page. (BTW I think you can maybe also request access to Notion pages - if so, feel free to do that in future!)

That's a good point about the derivative. I would have thought that given the smoothness of the curve, it should converge easily, but you're definitely a much stronger mathematician than me so I trust your judgement!

However the main question here is whether we should really be doing this estimation on-chain - please see https://github.com/neutral-protocol/dynamic-fee-pools/issues/38#issuecomment-1916932139 and https://www.notion.so/toucan-protocol/Redemption-with-CHAR-spend-as-input-c88f4c4c6c7a4b1b814d8ce20681bf31?pvs=4#e1c6949b8fa2494986a413b31c43c203

[aspiers]

To be clear: if we do it on-chain atomically as part of the redemption, then the accuracy/gas trade-off is challenging and so far it's yet to be proven where there's a sweet spot in this trade-off for acceptable UX. If we do it off-chain with "slippage" protection, then accuracy and gas both cease to be issues.