Add ReserveTax and ReserveTaxPool

[zramsay]

ref: cosmos/gaia#61

closed (?) from spec in feature/provisions branch in gaia repo

[cwgoes]

(comment moved to https://github.com/cosmos/cosmos-economics/issues/32)

[cwgoes]

Should ReserveTax and ReservePool be kept in the staking state?

Where can ReserveTax fee deduction be implemented - the x/auth ante handler, where fees are deducted? Ideally it would be specific to a Cosmos Hub module, as presumably most zones won't want this kind of reserve pool

[rigelrozanski]

From slack Convo:

rige
What you’re saying is actually incorrect - the fee collection should be in the AnteHandler, but the fee-reward distribution logic is a part of the staking module

cwgoes
OK, wasn't sure, at the moment deductFees just erases coins from existence - so those should go into a common FeePool account then, then get redistributed later in the staking module? (edited)

---

In the fee pool design for staking there is already a fee pool account - maybe we should pass in some limited keeper to the antehandler which informs where to move the fees too... Or maybe just an account address would be enough. If it was an interface on the keeper being passed in, we could allow for the staking keeper to execute arbitrary logic as to how the fees taking is handled. For instance, I don't the the fee pool should be an actual "account" it only needs to be a Coins which is accessible only from protocol.

[cwgoes]

Can we separate the fee pool and the staking implementation of fee distribution if possible? Charging fees on transactions - and sending those fees somewhere, so the coins aren't just destroyed - is something most (all?) applications using the Cosmos SDK will want to do, whereas the ReserveTax / ReservePool are Cosmos Hub-specific features.

How about the AccountMapper in x/auth, which handles fee logic in its AnteHandler, also keeps track of the current fees - without a special account, just as a Coins value incremented when fees are deducted in deductFees, and exposes functions which other modules can use to modify the fee pool? x/stake, for example, could then allocate fees at the end of every block (or whatever interval is desired, possibly some efficiency concerns) and reset the AccountMapper's fee pool to zero.

[rigelrozanski]

Can we separate the fee pool and the staking implementation of fee distribution if possible

of course, but I don't see the problem with requiring passing in an function to the feeHandler in auth which dictates what happens to the fees. - yeah maybe it can already happen through AccountMapper somehow - need to dig in - also need to expose this interface in baseapp I'd imagine, we want it's requirement to be fulfilled at a high level

[cwgoes]

Fee calculation / tracking / allocation doc reference - https://github.com/cosmos/cosmos-sdk/blob/master/docs/spec/staking/old/spec2.md#fee-calculations

@sunnya97 Did you want to work on fees (you mentioned)? I think this has to be done as part of the full fee implementation, it isn't a standalone task.