Updated Spec

[GalloDaSballo]

Spec changes from main

• User Power Accounting is done in the same way as the original code

• Depositing and WithdrawingLQTY requires resetting voting power

• Voting also resets voting power

• Resetting votes in the last day of the epoch could result in being unable to vote again, only vetoing can be performed at that time

• However, changing votes allows re-voting, meaning the loss of votes can happen only to those that reset their votes when increasing their deposits

• All functions to retrieve initiative and global state will return data without any conditional output

• Initiatives all use the getInitiativeState function to univocally be in a specific state

• Initiative votes are snapshotted at the epochStart, same for registering an initiative, this means that some people will have to wait for the next epoch to add an initiative

• Initiative have a WARM_UP on the epoch they are added, making it so that nothing can be done to them, in the following epoch they can be voted on or vetoed, if an initiative is vetoed sufficiently, it will not receive any reward and it will be `UNREGISTERABLE\ in the next epoch

Latest invariant testing runs

Broken Properties
https://getrecon.xyz/shares/a90feef0-6ae0-465a-bc19-d6011b5c5e87

check_unregisterable_consistecy is part of the known gotchas
property_BI05 is due to an incorrect implementation, which is partly due to the complexity in how the BribeInitiatives are coded, this is left broken to suggest fixing it and to consider rewriting the way old balance lookups are done (perhaps without requiring user input) as to streamline the UX

Optimization Tests

https://getrecon.xyz/shares/4322cb57-533a-46ff-9bd8-4703aea725dd

All known Gotchas

• Votes that are vetoed will cause a loss of emissions to the remaining voted initiatives that are claimable
• Initiatives that are UNREGISTERABLE must be unregistered on the first epoch in which they get this status, if that doesn't happen, idle votes may cause them to go back to being CLAIMABLE
• CLAIMABLE initatives may be unregistered as they may still meet the criteria if nobody claims
• A truncation error in _calculateAverageTimestamp causes the timestamp to be closer to the future, this may be weaponizable or may cause slight losses to initiatives. The code was magnified by a factory of 1e26 to make the rounding error require 100MLN LQTY to cause 1 second of losses
• The same magnification may make the code somewhat inconsistent as all inputs are magnified by that value, but some view functions do not
• Integrators must be careful around this magnification decision as to not introduce more bugs
• The magnification may also make overflows more likely, although most of those lines have been tested