Spec Changes

[GalloDaSballo]

Executive Summary

The key changes applied have been:

• Separate decisions from view variables when it comes to snapshots
• Centralize most FSM logic in a new function getInitiativeState
• Change Snapshot functions to possibly return view update values
• Fix a desynch in calculateVotingThreshold by making it state changing
• Make Hooks safe by introducing safeCallWithMinGas
• Fixed overflows by changing Math and fuzz testing it

Initiative Status is one per epoch

At epoch flip all values for a Initiative are cached in a snapshot
Altering any value in the state has no impact on the result on the snapshot values
The snapshot determines what the Initiative can do

The states are described by the following enum

    enum InitiativeStatus {
        NONEXISTENT, /// This Initiative Doesn't exist | This is never returned
        COOLDOWN, /// This epoch was just registered
        SKIP, /// This epoch will result in no rewards and no unregistering
        CLAIMABLE, /// This epoch will result in claiming rewards
        CLAIMED, /// The rewards for this epoch have been claimed
        UNREGISTERABLE, /// Can be unregistered
        DISABLED // It was already Unregistered
    }

Initiative Snapshot stores all storage value

We no longer have any conditional logic in snapshots
The conditional logic is handled in getInitiativeState

Rewards allocation logic is deterministic from the storage values

Meaning that initiatives that have been vetoed will still report having votes, but they will not be eligible for rewards

TO FIX: Vetos on voted initiative cause the total votes to distribute less rewards than intended

BribeInitiative Spec

The following is the spec of how the BribeInitiative work as of today

This include multiple known issues

Functionality

The BribeInitiative allows anyone to add a bribe token that will be rewarded to voters

The distribution is pro-rata on a simple:
Vote Weight * Rewards / Total Vote Weight

For the initiative

The outcome of voting has no impact on the bribes distribution

The logic works as follows:

• onAllocateLQTY we store the total votes for a user and for the initiative

When determining the votes at the time of an epoch, we traverse the linked list to find the most recent snapshot of user and total votes

Claiming:

• You can only claim rewards from past epochs

Bribing:

• You can only bribe rewards in the future

That means that as a user, you will have to wait 1 epoch before any bribe is added
And you will be able to claim said bribe on the flip of the epoch for which the bribe was added

Known Issues

The following are known issues with the current implementation

While the findings have different priorities, all impacts are low severity

Any higher severity impact not listed here should be considered a not known Bug

• You have to wait an extra epoch -> Fixed in EXP - Rational Flow for Bribes and Claims #25

• There can only be one bribe token

• Dust amounts can be stuck due to integer division

• The doubly linked list serves no clear purpose

V2-gov/src/BribeInitiative.sol

Lines 106 to 111 in 5f863c3

	if (totalVotes != 0) {
	(uint88 lqty, uint32 averageTimestamp) = _decodeLQTYAllocation(lqtyAllocation.value);
	uint240 votes = governance.lqtyToVotes(lqty, block.timestamp, averageTimestamp);
	boldAmount = uint256(bribe.boldAmount) * uint256(votes) / uint256(totalVotes);
	bribeTokenAmount = uint256(bribe.bribeTokenAmount) * uint256(votes) / uint256(totalVotes);
	}

        if (totalVotes != 0) {
            (uint88 lqty, uint32 averageTimestamp) = _decodeLQTYAllocation(lqtyAllocation.value);
            uint240 votes = governance.lqtyToVotes(lqty, block.timestamp, averageTimestamp);
            boldAmount = uint256(bribe.boldAmount) * uint256(votes) / uint256(totalVotes);
            bribeTokenAmount = uint256(bribe.bribeTokenAmount) * uint256(votes) / uint256(totalVotes);
        }

Will generate dust amounts