Registering new Wallet Schemes 1.1

In the original wallet scheme v1.0 we found a bug when changing permissions which meant the new permissions were not applied, only the ones set when the scheme was initialised. Because of this we quickly fixed the bug and released version 1.1 to fix the issue.

We previously deployed this new version of the Quick Wallet Scheme (QWS) - a scheme designed to only control its own funds and to move quickly.

However, upon attempting to update the permissions for this scheme we realised there had been an issue deploying it. We had accidentally set the initialise parameter for doAvatarGenericCalls to true when it should have been false. This was not a bug but simply human error for not spotting it.

For that reason, we are detailing the steps and logic behind the new deployment and registration here for anyone to follow and verify:

  1. Go to the new registration proposal (​​

  2. Verify the SchemeRegistrar is being used

  3. Open the advanced call details by clicking the magnifying glass

  4. Verify the call is from avatar to controller calling registerScheme(address,bytes32,bytes4,address)

  5. Verify the first param is equal to the newly deployed address mentioned in the description as well as the initialisation transaction

  6. Verify the second parameter matches params hash seen on the previous (if a brand new scheme is being registered look below for advanced hash instructions) via the schemes info page (

  7. In the same location check the controller permissions on the right side of the old scheme match the third parameter

  8. Lastly ensure the final parameter is the avatar for the relevant network

  9. The final step is the additional part missed last time. The newly deployed scheme in the block explorer should be linked in the description, click it (or navigate here yourself)

  10. From here go to the transactions tab and find the Initialize transaction / Alternatively you can go to the Code tab then “Read contract” if the contract is verified

  11. Clicking on the transaction we can see the logs at the bottom

  12. Ensure these all make sense given what the new scheme should be allowed to do.

Most importantly that:

doAvatarGenericCalls is likely false

All addresses are correct for the network in use (These can be found in dxvote repo config files)

maxRepPercentageChange is not too large (should be <=1 in most cases)

After this proposal executes we will update the permissions to allow for sending of DXD and WXDAI as well as all function calls. These will match previous proposals that have worked successfully and will only change the scheme being sued to the newly registered one.

We will also be unregistering old schemes both 1.0 and failed 1.1 soon.

We encourage anyone with questions or concerns to contact the DXgov team.