Decide whether the consumer can update ConsumerRedistributeFrac

[mpoke]

Currently, ConsumerRedistributeFrac, i.e., the fraction of tokens allocated to the consumer redistribution address during distribution events, which means it could be modified by the consumer through governance. I'd argue that the consumer should not be able to change this parameter without the consent of the provider chain. Thus, for now, we should add this as a field of the CreateChildChainProposal. Later we could allow this to be change by submitting a TX to the provider or through an IBC packet.

After discussions, the preferred solution is to keep the ConsumerRedistributeFrac hardcoded in the consumer chain. As a result, the validators on the provider chain can check the value when auditing the consumer binary, and the consumer chain cannot update it through governance.

[mpoke]

@okwme Do you think we need for the V1 release to enable the consumer chain to change the ConsumerRedistributeFrac after deployment?

[jtremback]

IMO we should approach governance abilities on consumer chains with a whitelist approach, not a blacklist approach. The default consumer chain should have no or very few governance capabilities. Capabilities that get whitelisted can be debated during the consumer chain proposal vote. So, by default, the answer is that it should not be possible for consumer governance to update ConsumerRedistributeFrac

[jtremback]

IMO you should update this issue to be "Make consumer chain governance whitelist"

[mpoke]

I opened another issue regarding whitelisting consumer chain parameters (see #82). I still think though that ConsumerRedistributeFrac should be specified in the governance proposal since it is part of the contract between the provider and the consumer.

[mpoke]

Solution: Hardcoded in the consumer chain code.

[rigelrozanski]

Agree that we should hardcode it so that providers need to sign off on the new binary, hence they'd also sign off on modified distribution amounts.