Granular updates to credit class fee and basket fee params

[ryanchristo]

Summary

Opening this issue to further discuss and track whether we want to provide support for adding, updating, and removing a single fee from the list of fees for parameters such as credit class fee and basket fee.

While migrating from legacy params to ORM params, the initial implementation (added in #1349 and #1354) adopts the same approach as legacy params, which requires updating the complete list of params.

If we want to make any changes, such changes should be included before the next release (i.e. v5.0).

Problem Definition

Updating fee params prior to message-based governance proposals required updating the whole list of fees in each proposal. We now have the option of adding, updating, and removing a single fee from the list.

Adding, updating, and removing individual fees from the list of fees would require three messages rather than one. The tradeoff would be more granular updates to fees and a better user experience with regards to not including existing fees when adding a fee but this would require more messages, one for each action (add, update, and remove), which might be excessive.

Proposal

(1) Keep the current implementation with one message that updates the entire list
(2) Add more granular messages for adding, updating, and removing a single fee from the list
(3) Switch to single fee with only one update method (as previously proposed in #1165)

---

For Admin Use

• Not duplicate issue
• Appropriate labels applied
• Appropriate contributors tagged
• Contributor assigned/self-assigned

[clevinson]

Switching to a single fee makes sense to me. This would mean credit class fee, and basket fee are always in REGEN, right? I don't think we'd ever want globally to have a non-regen fee for basket or credit class creation.

[ryanchristo]

Switching to a single fee makes sense to me. This would mean credit class fee, and basket fee are always in REGEN, right? I don't think we'd ever want globally to have a non-regen fee for basket or credit class creation.

We would probably still use Coin just not repeated so a governance proposal could technically update the fee to another token denom but the idea is the fee would always be regen and we would burn the fee (as we currently are). A single fee would reduce complexity for users and simplify governance proposals and using and burning regen would help serve healthy tokenomics.