Hi - I may have some misunderstanding with the Governor contract's QuorumNumerator and how to determine if a member of the DAO's has enough tokens/voting power to reach quorum. Please help! Thanks
For testing my deployment, I had set an extremely high quorumNumerator and now that I'm pretty satisfied that everything is working, I dropped it to a more reasonable level of 1% of tokens to reach quorum. I have an account with more than enough ERC20 tokens by itself to reach quorum but the vote is always defeated (and I'm the only one voting at the moment). I preminted 1,000,000,000 (1 billion) tokens and the account I'm using has 12 million tokens - so that would be 1.2%. They have been delegated to myself. So my quorum numerator is 1 and my denominator is the standard 100. Shouldn't having my user account vote '1' on the proposal be enough to have the vote pass?
Please note that the bulk of the tokens still belong to the deploying address - I haven't transferred them to the treasury's address (the timelock) yet. Don't know if that matters...
But I'm totally confused - am I mistaken how this all works? Am I missing something?
Thanks for the help
Without a pointer to the contracts it's difficult to know what is going on. Here are some checks that might help you:
- check that the governor variable are set properly by calling the view function (particularly if you are using an upgradeable version)
- check that your tokens are delegated and that the
getVotes returns the expected number
- make sure you create the proposal AFTER having the votes delegated
- vote (1 is the right value to approve)
- check the
proposalVotes to make sure your vote was registered
- after the end of te voting delay, you check the status
If you are still experiencing issue, please provide a link to a testnet instance or code to reproduce the issue.
Still unable to get a proposal passed even though my account had enough delegated voting power before I added the proposal. Everything seems to be set correctly. Here are the contracts:
Latest failed proposal:
Addr 0xbc4030471511866E7015e3E2685d8AdE61fC7F0F had more than enough ERC20 voting tokens delegated to meet quorum. I am stumped. Thanks for your help
The proposal that you mention appears with state Succeeded. And I can see that you were able to create and queue another proposal after this one. So it looks like it's been resolved.
Thank you. I'm still a bit new to web3 development and so I always think I'm the one that's made a mistake. This one is on Tally. They are mistakenly displaying the proposal state as Defeated. That's kind of a big deal! I suspect that, although it's only displaying wrong under certain conditions, I think they are thinking that the Proposal State enum values are 1-based instead of being 0-based.
Hello @chrisb! We're going to look into this and see what the problem is. We did have some backend problems come up in the past day that we're working on, so maybe it was a part of that, but regardless we will find the root cause!
Hi @chrisb. We've fixed the error. The problem was that Tally didn't see the quorum change from an earlier proposal, so it thought that some of the proposals failed due to missing quorum. Should work now.
Thank you to you both! Problem solved