Feat: Pool Fees - Charge on Cash asset directly

[mustermeiszer]

Description

Currently, Issuers will often off-ramp the whole capital that is invested into a pool into their bank accounts as trading onchain is not yet possible. The capital is currently tracked in the Cash assets, assets that are valuated with Cash.
Therefore, transaction fees related to offchain actions are directly payed from said bank account. Now, charging these fees with the current fee setup is hard, as issuers do not want to get reimbursed from the pool. They have already used the pool money for paying said fees. Rather they want to make a bookeeping entry that some capital was used for paying fees.

Research/based on

→ Create fee assets with target Reserve/CashAsset
→ Charging on CashAsset emits Paid event
→ Uncharging on CashAsset emits UnPaid event?

• Subquery needs to reduce total paid with receiving Unpaid events
  → Needs to have a limit per time pased based on calender time
• e.g. A yearly chargeable fee, that is created on the 23.12.2024 can charge the WHOLE amount of the year
• Fees of this type are also accruing
  • e.g. A yearly chargeable fee, that is created on the 23.12.2024 can charge the amount of TWO years on the 01.01.2025

Additional Features

• Charge at most balance of CashAsset
• Have a limit in USD - not compared relativ to NAV
• Allow to add and remove accounts that are possible chargers for a given fee - i.e. not only allow destination to charge

How will this affect the code base

• Improve usability of pool fees for issuers

What are foreseen obstacles or hurdles to overcome?

• TBD

[wischli]

IIUC, these are more or less "one time" fees in that they can be removed once the USD limit is reached. If so, it doesn't make sense to couple them with a time component (e.g. yearly).

Unforeseen issues:

• Requires oracle for CFG to USD conversion

[mustermeiszer]

IIUC, these are more or less "one time" fees in that they can be removed once the USD limit is reached. If so, it doesn't make sense to couple them with a time component (e.g. yearly).

Why? The limit is per period, but compounding over periods. So daily 50EUR would mean you can charge 250EUR after 5 days if you haven't charged anything in between.

Requires oracle for CFG to USD conversion

Why do we need that? Charges are in pool currency?

[wischli]

Requires oracle for CFG to USD conversion

Why do we need that? Charges are in pool currency?

🙈 Weekend is calling, sorry.

IIUC, these are more or less "one time" fees in that they can be removed once the USD limit is reached. If so, it doesn't make sense to couple them with a time component (e.g. yearly).

Why? The limit is per period, but compounding over periods. So daily 50EUR would mean you can charge 250EUR after 5 days if you haven't charged anything in between.

Had to re-read the above text and noticed that I overread a few words in my initial rush such that I understood that they could be pre-charged without any bounds. However:

A yearly chargeable fee, that is created on the 23.12.2024 can charge the amount of TWO years on the 01.01.2025

My question would be: Should these fees support completely flexible time bounds or is annually and potentially monthly sufficient?

Moreover, do I understand correctly that these fees never reduce the reserve because of

They have already used the pool money for paying said fees. Rather they want to make a bookeeping entry that some capital was used for paying fees.

[mustermeiszer]

My question would be: Should these fees support completely flexible time bounds or is annually and potentially monthly sufficient?

Yes, flexible timebounds would be greatl Just to that we can make the interval based on the calendar - I think we get all if we allow to choose

• x - secondly -> if timeframe is more than a month users should use monthly or yearly as those are not consistent. I.e. a month has different time passed depending on which month it is, same goes for year
• x - monthly
• x - yearly

[mustermeiszer]

Moreover, do I understand correctly that these fees never reduce the reserve because of

yes