search

1Hive / dandelion-voting-app

Contains the Dandelion Voting app which implements an ACLOracle
GNU General Public License v3.0
5 stars 8 forks source link

How to handle block tresholds in the ui #29

Closed fabriziovigevani closed 4 years ago

fabriziovigevani commented 5 years ago

In the contract, the conditions for a vote to be open or not are the following:

return votingPowerAtSnapshot > 0 && getBlockNumber64() >= vote_.startBlock && getBlockNumber64() < vote_.startBlock.add(voteDurationBlocks);

Frontend wise, technically votes will already have started in startBlock - 1 since when performing a tx at that block, the block number that will include said tx will be startBlock. (same logic goes for ending and execution)

So for instance if the startBlock is 20 and the block time is 15, users will be able to vote in the 15 second period from 19th block and the startBlock. This means that they will not be able to vote in the 15 second period from endBlock -1 to endBlock.

There are two options:

  1. Leave it as it is right now and maybe put a warning or info message stating this in case we are at the endBlock - 1

  2. Convert every threshold block to its previous block on the frontend, unfortunately this comes with other complications (e.g vote is closed in the ui but is not in the contract, so when performing a call to canVote or canExecute the result is not consistent).

Speaking with @willjgriff we think that leaving as it is, is ok.

What do you think?

rperez89 commented 5 years ago

I think that going with the option 1 is the best option right now. If we set the endTime as endblock -1 we are not going to have the problem that the timer keeps running but you can not vote right?

fabriziovigevani commented 5 years ago

Yes exactly, i think also for now is ok and if in the future we see a problem can consider changing it

willjgriff commented 5 years ago

Seems like a simple fix on the front-end. If it's consistent across the front-end UI components I think it's worth doing.