The current implementation of the incentives contract has a few improvements that can be made.
One that is arguably easiest to make is, currently, in order to start a new penalty period and distribute the previous period's rewards, a privileged party needs to send a NewPenaltyPeriod msg to the contract. This creates reliance on the party to do so, and to do so at regular/agreed-upon intervals.
An alternative design is to
- define a
PERIOD_DURATION variable, configurable by owner (most likely governance)
- embed the
NewPenaltyPeriod trigger into other interactions with the incentives contract that is executed whenever more than PERIOD_DURATION has passed since the last period
This way, new penalty periods will be triggered automatically by the community, without having to rely on a single party.
And although the added execution might increase the transaction cost for the user slightly, this cost should be amortized between users given a long enough timespan
The current implementation of the
incentivescontract has a few improvements that can be made.One that is arguably easiest to make is, currently, in order to start a new penalty period and distribute the previous period's rewards, a privileged party needs to send a
NewPenaltyPeriodmsg to the contract. This creates reliance on the party to do so, and to do so at regular/agreed-upon intervals.An alternative design is to
PERIOD_DURATIONvariable, configurable by owner (most likely governance)NewPenaltyPeriodtrigger into other interactions with theincentivescontract that is executed whenever more thanPERIOD_DURATIONhas passed since the last periodThis way, new penalty periods will be triggered automatically by the community, without having to rely on a single party.
And although the added execution might increase the transaction cost for the user slightly, this cost should be amortized between users given a long enough timespan