Can't Manage DAO Neuron

We have been unable to setup a local test for our neuron_controller so we are going live with it testing as we go.

We have successfully create the DAO controlled neuron, and it was claimed by the DAO. The function responsible for this was stake_nns_neuron:

The next thing to do increase the dissolve delay to 8 years, we have a script to manage the neuronin the same file.

However, when running the script we receive the following error:

1 Like

If I understood the logs correctly, the proposal was trying to execute a generic nervous system function added here and it seems to have failed when executing the proposal because of payload parsing, after its validation passed while creating the proposal.

Is it possible that the payload format accepted by the validator is different than that accepted by the executor? Didn’t look into your repo too much, but from searching “validateManageDAONeuron” I got those 2 methods and they do seem to take different arguments. Could it be the reason?

1 Like

Hello sir,

Hamish from OpenChat came back to me about not long ago and has noticed the format of my payload is off.

I new proposal will be raised shortly to update the backend, then a new proposal will be made to test the manage neuron but hopefully this has been resolved… I will add the solution if it is.

Also yes, you are correct, the payloads did not match on the validation and the execution, that is being fixed.

Hi Jason,

The proposal executed:

unfortunately it didn’t update to 8 years:

If you grab the payload and feed it into didc:

$ didc decode 4449444c056b01c6b3bb9106016c01a78882820a026e036b0190f29afe07046c018dc3b2b3037c010000010080b8a6f800

  variant {
    1_647_237_574 = record {
      2_688_582_695 = opt variant {
        2_143_729_936 = record { 913_088_909 = 252_288_000 : int }

We can see that 252_288_000 is an int. However, I believe additional_dissolve_delay_seconds should be a nat32. AFAIK, int is not a subtype of nat32 so something encoded as int cannot be decoded as nat32. (I’m not a candid expert, so @chenyan in case I’m wrong)

It might be worth looking into how you prepared the payload. And if that’s indeed an issue, one way to prevent it in the future is for the validator to return something that’s not just “Proposal is valid”, since I believe the validator will see something like operation = null instead of operation = opt variant { IncreaseDissolveDelay = record { additional_dissolve_delay_seconds = 252_288_000 }}. Essentially, if the validator can turn the structured data into a text format, it can help the proposer as well as voters to examine the payload.

Hi Jason,

Sorry for not updating you sooner. I did have the wrong payload, and it was missing from the validation function, and I was using the SECP256K1.ID.Test_Key when i tried to update it and not Key_1, the key the neuron was staked with.

A proposal to update the neuron controller has executed to fix all this just now and I will raise the proposal to try again. I will let you know.

Hi Jason,

So I’m travelling to Zurich but the proposal executed to update the neuron to 8 years but it didn’t work. Here is what I executed:

And this is the stored response from the request:

Saying it didn’t have an operation when it did?

The Candid encoder seems to have encoded the 252_288_000 into an int but the function expects a nat32. (This is visible in Jason’s message above.) Can you maybe do a 252_288_000 : nat32 explicitly?

I hope you have a safe flight, looking forward to meeting you tomorrow!

1 Like

Sorry I’ve been fixing so many things trying to get it staked I missed that.

Let me try again.

I’m way too scared to fly but it’s only a 12 hour drive. Looking forward to meeting you too.


So I just had the wrong payload, the neuron has been configured to 8 years now using the correct payload:

(variant { Configure = record { operation = opt variant { IncreaseDissolveDelay = record { additional_dissolve_delay_seconds = 252460800:nat32 } } } })