@0xmichalis One thing to note is that we can't calculate exact amount of POOL that's requested by user, the reason is the method we implement this is by iteratively searching for TCO2 that would yield the closest POOL amount.
Due to caping the amount of iteration we probably won't land of exact numer like 10POOL, but rather something like

9.99934 POOL - 9.123 TCO2

On top of above, we may need to have this estimation function outside the redeemInMany call due to gas usage. So the flow would be

call estimateTCO2(uint256 poolAmount) returns uint256 -> estimatedTCO2
call redeemInMany(estimatedTCO2, maxPOOLamount, ....)

where maxPOOLamount would check that the result is not exceeding that amount in redeemInMany after making redemption - similarly to slippage protection in uniswap.

@PawelTroka

One thing to note is that we can't calculate exact amount of POOL that's requested by user, the reason is the method we implement this is by iteratively searching for TCO2 that would yield the closest POOL amount.

Why isn't it possible to calculate this exactly rather than via iteration?

Regarding this:

This issue tracks the missing functionality of calculating the amount of TCO2 received via redemption when providing POOL amount. Which is opposite to what's available rn.

I just wanted to check my understanding here and try to explicitly document what we are talking about for clarity. I think the key points about our current redemption code are as follows:

1. The fee calculation currently relies on:

   b = (current_asset_volume +/- deposit/redemption amount ) / (total_pool_volume +/- deposit/redemption amount)
   

   where in the redemption case, deposit/redemption amount refers to the amount of TCO2 received by redemption

2. The fee is taken in POOL, which means that the fee doesn't get redeemed and therefore doesn't affect pool composition.

So with this approach we first need to know the amount of TCO2 received by redemption, then we can calculate the fee, and that gives us the amount of pool the user will spend:

    POOL_to_spend = TCO2_to_receive + redemption_fee(TCO2_before, TCO2_before - TCO2_to_receive, totalTCO2supply)

So the challenge would be to rearrange this equation to solve for TCO2_to_receive given known inputs for POOL_to_spend and TCO2_before, right?

Similarly, with depositing, currently we first need to know the amount of TCO2 the user wants to deposit, and then we can calculate how much POOL they receive via:

    POOL_to_receive = TCO2_to_spend - deposit_fee(TCO2_before, TCO2_before + TCO2_to_spend, totalTCO2supply)

With depositing I guess it's less important to allow the user to choose how much POOL they'll receive and calculate the amount of TCO2 needed for that, but if we wanted to do that, we'd have to solve this equation for TCO2_to_spend given known inputs for POOL_to_receive and TCO2_before.

@PawelTroka

One thing to note is that we can't calculate exact amount of POOL that's requested by user, the reason is the method we implement this is by iteratively searching for TCO2 that would yield the closest POOL amount.

Why isn't it possible to calculate this exactly rather than via iteration?

I think I answered my own question in https://www.notion.so/Redemption-with-CHAR-spend-as-input-c88f4c4c6c7a4b1b814d8ce20681bf31

On top of above, we may need to have this estimation function outside the redeemInMany call due to gas usage. So the flow would be

call estimateTCO2(uint256 poolAmount) returns uint256 -> estimatedTCO2
call redeemInMany(estimatedTCO2, maxPOOLamount, ....)

where maxPOOLamount would check that the result is not exceeding that amount in redeemInMany after making redemption - similarly to slippage protection in uniswap.

If they are done in two separate calls then it loses the value doing the estimation on-chain, which is to estimate and redeem atomically in order to avoid race conditions with other deposits/redeems. This way we can guarantee the exact result requested.

If instead we accept the race conditions and defend with limit parameters like maxPOOLamount like you suggest, then we can do the estimation off-chain in which case it can be way more accurate and we don't have to worry about gas.

Both options seem viable to me, but we need to choose between them. Would love to hear what you guys think about this! Cc @0xmichalis

Documented in https://www.notion.so/toucan-protocol/Redemption-with-CHAR-spend-as-input-c88f4c4c6c7a4b1b814d8ce20681bf31?pvs=4#e1c6949b8fa2494986a413b31c43c203

Documented in https://www.notion.so/toucan-protocol/Redemption-with-CHAR-spend-as-input-c88f4c4c6c7a4b1b814d8ce20681bf31?pvs=4#e1c6949b8fa2494986a413b31c43c203

@aspiers please share above, unable to access.

Documented in https://www.notion.so/toucan-protocol/Redemption-with-CHAR-spend-as-input-c88f4c4c6c7a4b1b814d8ce20681bf31?pvs=4#e1c6949b8fa2494986a413b31c43c203

@aspiers please share above, unable to access.

I gave you access @kosecki123

On top of above, we may need to have this estimation function outside the redeemInMany call due to gas usage. So the flow would be

call estimateTCO2(uint256 poolAmount) returns uint256 -> estimatedTCO2

call redeemInMany(estimatedTCO2, maxPOOLamount, ....)

where maxPOOLamount would check that the result is not exceeding that amount in redeemInMany after making redemption - similarly to slippage protection in uniswap.

If they are done in two separate calls then it loses the value doing the estimation on-chain, which is to estimate and redeem atomically in order to avoid race conditions with other deposits/redeems. This way we can guarantee the exact result requested.

If instead we accept the race conditions and defend with limit parameters like maxPOOLamount like you suggest, then we can do the estimation off-chain in which case it can be way more accurate and we don't have to worry about gas.

Both options seem viable to me, but we need to choose between them. Would love to hear what you guys think about this! Cc @0xmichalis

I think regardless we need to have the slippage protection. Basically you need to assume there is MEV in play.

To me the best that covers all is to estimate off-chain and execute on-chain, similarly to AMMs. The diff here is that we cannot have 'exact' amounts as we approximate in case of POOL input.