DataHighway Node. A blockchain being built with Substrate to become a parachain on the Polkadot network. Planned features include a decentralized LPWAN roaming hub for LoRaWAN IoT devices and network operator roaming agreements, participative mining, an inter-chain data market, and DAO governance. http://www.datahighway.com
Proposed changes to perform a forkless chain upgrade so that the community may use on-chain voting to propose to transfer DHX tokens from the DHX DAO Unlocked Reserves (Treasury) to a Multisig Proxy account for subsequent transfer to topup a Supernode within a reasonable timeframe. Refer to https://github.com/DataHighway-DHX/documentation/pull/129
We need the community to decide what are reasonable parameters to change in the democracy pallet, as in this PR i've just chosen very short durations to make it easy to test in a development environment (i.e. launch period, voting period, and cooling off period of only 5 minutes instead of 28 days; enactment period of 5 mins instead of 30 days; fast track voting period of 4 minutes instead of 3 days)
Steps: Test that it works on "dev" chain locally
1) Generate Wasm file to use later for forkless upgrade
Checkout this branch 'luke/1288-upgrade-democracy-faster' and build it to generate a Wasm file of v3.0.6 where democracy parameters are faster for forkless upgrade (i.e. launch period, voting period, and cooling off period of only 5 minutes instead of 28 days; enactment period of 5 mins instead of 30 days; fast track voting period of 4 minutes instead of 3 days)
i.e. generate a preimage to transfer 1 DEV from Alice to Bob, using "balances > forceTransfer", copy the preimage hash and then use it to create a proposal, then second the proposal. note that the launch period shown in the UI is 28 days at https://polkadot.js.org/apps/?rpc=ws%3A%2F%2F127.0.0.1%3A9944#/democracy
After the sudo upgrade, the UI changes from v8 to v9, but still shows v3.0.5 since that was the version at genesis chain (then on-chain upgrade to v3.0.6)
Observe that Launch Period still shown as 26 d 4 hrs in UI, even though we just did an upgrade to reduce it to 5 mins
The previous "proposal" that we created prior to the forkless upgrade that was seconded has now changed from being listed in the "proposal" section to the "referenda" section (since it has already satisfied the duration required by the new runtime parameters), and has only ~4 mins remaining for voting, and ~9 mins to activate.
Vote "Yey" on the referenda
Wait ~4 minutes for the voting period to end, then it disappears from "referenda" section, and is added to scheduled "dispatch" queue.
Important: this is still a Sudo transfer, so must only be used between the Treasury and Multisig Proxy. Only normal transfer is allowed between Multisig Proxy and Supernode (since Supernode will not accept transfers using Sudo)
Update 16th Aug 2021 - Low priority on-hold
Proposed changes to perform a forkless chain upgrade so that the community may use on-chain voting to propose to transfer DHX tokens from the DHX DAO Unlocked Reserves (Treasury) to a Multisig Proxy account for subsequent transfer to topup a Supernode within a reasonable timeframe. Refer to https://github.com/DataHighway-DHX/documentation/pull/129
We need the community to decide what are reasonable parameters to change in the democracy pallet, as in this PR i've just chosen very short durations to make it easy to test in a development environment (i.e. launch period, voting period, and cooling off period of only 5 minutes instead of 28 days; enactment period of 5 mins instead of 30 days; fast track voting period of 4 minutes instead of 3 days)
Steps: Test that it works on "dev" chain locally
1) Generate Wasm file to use later for forkless upgrade
2) Run existing chain and generate an on-chain governance proposal to transfer tokens between two accounts that will use sudo
3) On-chain upgrade to faster democracy
Important: this is still a Sudo transfer, so must only be used between the Treasury and Multisig Proxy. Only normal transfer is allowed between Multisig Proxy and Supernode (since Supernode will not accept transfers using Sudo)