EstateDAO developer neuron unable to vote on proposal

Developers Command Line Tools
1

We have setup a developer neuron using quill. Specifically this one:
047d950b66f4627c362de28388879fcebe3a7a8d66c3f93245d57af6cb6aff8a

We are trying to cast a vote on this proposal.

However, we’re seeing this when we try to vote using quill:

image
image827×543 16.8 KB

This is the voting script we are executing:

export IDENTITY_NAME="estate_dao_sns"
export PEM_FILE="$(readlink -f ~/.config/dfx/identity/${IDENTITY_NAME}/identity.pem)"
export CANISTER_IDS_FILE="./sns_canister_ids.json"
export NEURON_ID="047d950b66f4627c362de28388879fcebe3a7a8d66c3f93245d57af6cb6aff8a"
export PROPOSAL_ID="1"
export VOTE="y"

dfx identity use "${IDENTITY_NAME}"

./quill sns \
    --canister-ids-file "${CANISTER_IDS_FILE}" \
    --pem-file "${PEM_FILE}" \
    register-vote \
    --proposal-id ${PROPOSAL_ID} \
    --vote ${VOTE} \
    ${NEURON_ID} > ./scripts/2024/7-vote-on-proposal.json

./quill send --yes ./scripts/2024/7-vote-on-proposal.json

Please note that we would need to use this neuron for voting as this is our developer neuron that has been shared publicly for SNS participants to follow on all our social channels.

Please help.

@lara @bjoernek

2 Likes
2

Hi @estatedao,
was the proposal that you are voting on created before the neuron was set up or afterwards?
If the proposal was already there, the neuron would not be eligible: when a proposal is created, the governance canister takes a snapshot of each neurons’ voting power - so only neurons who are eligible to vote at this point can then vote on the proposal.

2 Likes
3

Thank you for the response @lara

The neuron was created before but we discovered that it did not have any dissolve delay set. We had to do that as a separate step with quill.

The dissolve delay was set with the following command after the proposal was submitted:

export IDENTITY_NAME="estate_dao_sns"
export PEM_FILE="$(readlink -f ~/.config/dfx/identity/${IDENTITY_NAME}/identity.pem)"
export CANISTER_IDS_FILE="./sns_canister_ids.json"
export NEURON_ID="047d950b66f4627c362de28388879fcebe3a7a8d66c3f93245d57af6cb6aff8a"

dfx identity use "${IDENTITY_NAME}"

./quill sns \
  --canister-ids-file "${CANISTER_IDS_FILE}"  \
  --pem-file "${PEM_FILE}"  \
  configure-dissolve-delay \
  --additional-dissolve-delay-seconds 80000000 \
  ${NEURON_ID} > ./scripts/2024/6-set-dissolve-delay-to-be-able-to-vote.json

./quill send --yes ./scripts/2024/6-set-dissolve-delay-to-be-able-to-vote.json

Do you think that could be the reason for this behavior? Do we need to submit another proposal for this neuron to be eligible to vote?

4

Yes indeed this could be the reason!
Since neurons can always change and have a different voting power / vote eligibility when they change dissolve delay, stake, and age, the governance takes all of this information at exactly the same time.
So for each proposal, what matters is the moment when the proposal was submitted.
This means that neurons who did not have enough dissolve delay at the time when the proposal was created, then it will not be considered for this proposal.

Right, this also means that if you now create a new proposal when this neuron is already set up, then it should be able to vote on the proposal.
I hope this helps!

2 Likes
5

Could you clarify whether or not neuron 5f5b05c5d0f0f086db7eb8e14607bc095f6b7628f443c1a60bc3510b7b56853d
belongs to the team?

***I see it now says EstateDao on it. I dont believe there was any identifiers on it yesterday when the original proposal hit.