Goverance set CRT constraints

[ignazio-bovo]

List with proposed constraints that can be set by governance and the rationale, behind.
This is meant to be an extension from #4151 and to be referenced by the PR

Revenue Split

• timeline_max_duration: this could prevent the CC from setting potentially too long staking period, I think this is more of a usability issue
• timeline_min_duration: no real attack vectors comes to mind, but I think this is more of a usability issue
• split_percentage this value ranges from [x%, 100%]. For a 100% amount the CC takes all the profits from the channel revenue (and I think this should be allowed). Like wise allowing x to be zero (user doesn't take any of the profits) shouldn't be a big problem usability

Patronage

• patronage_rate_min_value patronage rate is a % value. Allowing it to be set to 0 is a way for the CC to limit the supply of CRT at a certain value (in case CC doesn't mint any other CRT), and I think it should be desirable from a usability point of view.
• patronage_rate_max_value: patronage represent a constant per block supply inflation rate that is destined to the CC. I think there's a real danger of the CC setting it to a particular high value and thus progressively reducing the % of supply owned by other CRT holders. vulnerability (in particular the CRT holders combined supply % will be reduced by (1 + patronage_rate)^b after b blocks)

Sale & Vesting Schedules

• cliff_amount: this is the amount that a CRT sale buyer gets immediately when vested. Setting it to 100% is equivalent to not having any vesting ongoing. I don't see any particular problem with low values either usability
• min_crt_amount_issued_in_a_sale: I just think that it doesn't makes sense to issue a sale with 0 tokens usability
• sale_max_price: computing price * amount_bought can result in a overflow and the buyer will see its sale purchase resulting in a error. So maybe some common sense checks should be provided (but maybe on the front end). Besides that I don't see any problem usability
• sale_min_price: I think this can be zero, allowing the CC to give away token for free if desired usability tokens are not minted in a sale but just distributed in exchange for JOYs
• sale_duration: I think this is a pure #usability thing. Clearly it doesn't makes sense for a sale to be 0,1,2, blocks in duration. And a user that takes more than 6sec (avg block production time) to click the buy button can miss the opportunity.
• number_of_upcoming_sale_updates: How would users react if the CC will repeatedly start to delay the sale start? It makes sense to limit this from a usability POV
• cap_per_member: It should makes sense to have a maximum cap (otherwise the no cap option would have been preferrable). Setting a cap to 0 however would exclude a user from a sale, so I think that a min/max_cap_amount should be set by governance to provide better usability
• we should set an absolute value for the transfer_destinations max amount, otherwise unbounded input vulnerabilities are possible to exploit ( vulnerability )

Token Issuance

• max_amount_of_token_issued_in_a_period: this makes sense to avoid low-quality projects (same rationale for limiting NFT applies here) usability . I think that only allowed verified channels (see channel verification) to issue CRT is a way to ensure that only quality tokens are issued.

AMM

• see Consideration On Amm parameters
• amm_sell/buy_tx_fee_pct are governance controlled parameters

All of the above parameters can be set by the governance through proposals