This commit fixes a bug in the `VotingContract` where any voting room
marked as `finalized` is not considered to be an active voting room,
even though, evaluation is still ongoing.
The fix adds a check that a voting room has to be either not marked as
finalized, or, if it is, it should not be evaluated, to be considered
an active voting room.
It also adds a test that ensures the fix is working as expected.
This fixes a bug that multicall isn't available on a local node. This
commit ensures we deploy it.
It also outputs multicall addresses for Goerli and Optimism, as those
will be needed when the app is deployed to production.
Something that came up during testing:
The deployment script didn't set the directory contract in both, the
voting contract and the featured voting contract, which resulted in
functoin calls to revert because they essentially didn't exist at the
addresses referenced in those contracts.
This commit fixes it by ensuring `setDirectory()` is called for both
voting contracts.
This commit addresses the issue that, when testing the contracts on a
local node, the test (deployer) account does not have any tokens to use
the voting contracts with.
This is fixed by minting tokens as the deployer of the mock SNT
contract.
The commit also adds the expect SNT contract instance as a return value
of the deploy function, ensuring its address is rendered in stdout when
running the script.
Adding it to the returned tuple however caused a "stack too deep" error,
which is why we had to remove one value from the returned tuple.
Since the `DeploymentConfig` contract instance address is irrelevant for actual
deployments, I've removed it from `DeployContracts.run()` and added an
additional function to retrieve it within tests.
This commit introduces a change that has been largely discussed in #65
Generally the idea is the following:
Prior to this commit, the amount of votes to be evaluated is unbounded, meaning we can potentially run out of gas when too many votes have to be evaluated in a single transaction.
To account for that, vote processing has to be batched based on a limit that is provided when the contract is called.
As a result of batching, finalization of votes can happen over multiple transactions which makes checking balances of voters tricky because evaluation happens at different blocks where balances might have changed.
That's why we're also introducing the use of MiniMeToken over standard ERC20 because it allows us to check balances of accounts at certain blocks.
This commit introduces the following changes in both VotingContract and FeaturedVotingContract:
Evaluation of votes now always happens in three places: When a voting is initialized, when votes are casted and when a voting is being finalized.
When initializing a voting or casting votes, the votes are evaluated against the current block, front-ends can therefore show a good estimation of the current vote state.
Only the "new" votes are evaluated, which should equal to the amount of votes being sent.
When finalizaing a vote, all votes are (re)evaluated against the block at which the finalization has started. This means with finalization, all votes are evaluated again to ensure they represent the latest state.
In terms of code this means:
_evaluateVotes() requires and additional limit, as a result of that finializeVoting() and finalizeVotingRoom() require a limit as well. castVotes() derives the limit from the vote amount that's being sent.
The ultimate goal will be to move the contracts package into its own repository that's based on our foundry template.
This commit adds foundry template config files and removes legacy
hardhat stuff.
This reimplements the hardhat testsuite using foundry for faster test
execution and ease of use.
Hardhat tests and configs are kept around on purpose so we can
transition slowly.
The `FeaturedVotingContract` comes with a check in `initializeVoting()`
that aims to ensure that the community that the voting is being
initialized for, has not been featured previously for #n votings.
This is denoted as the `cooldownPeriod`. If `cooldownPeriod = 1`, this
means there needs to be at least one voting which doesn't include the
community in question, that came *after* the voting that did.
The internal `_isInCooldownPeriod()` check has a bug which will return
false positives for any communiy that has been featured before,
regardless of `cooldownPeriod`s value.
When iterating previous votings, the contract actually needs to start
with the last one and iterate downwards, however it does the opposite so
it will never reach the correct votings to check.
This commit fixes the check and adds two tests to cover the case
accordingly.
Felicio Mununga
Jakub Kotula
Patryk Osmaczko
r4bbit
Pavel