This is xx network release v0.2.1.
This release includes only runtime changes, no client-side changes, so xxnetwork-chain upgrade is not strictly necessary.
Runtime versions:
- xx network: 201
- xx protonet: 200
- phoenixx: 200
Runtime information (using subwasm):
subwasm info xxnetwork_runtime-201.compact.compressed.wasm
๐๏ธ Runtime size: 0.796 MB (834,667 bytes)
๐ Compressed: Yes, 74.32%
โจ Reserved meta: OK - [6D, 65, 74, 61]
๐ Metadata version: V14
๐ฅ Core version: xxnetwork-201 (xxlabs-xxnetwork-0.tx1.au0)
๐ณ๏ธ system.setCode hash: 0x76cca0d527479a1c711f23dd437854207f7f33797494445c53997f822443a311
๐ณ๏ธ authorizeUpgrade hash: 0x07e07fbe214db26d11ea864400f633e421fe8a7864e4fa36663b77208291530a
#๏ธโฃ Blake2-256 hash: 0xf93192d5b27666920333c0e6b4195e2807c807568d91ee2220d074e86ebf6867
๐ฆ IPFS: https://www.ipfs.io/ipfs/QmUj51NjLNRDo6qvYiwbu5mJv9XM89se3Jm3VwYcF72Ufs
Runtime changes
Changelog:
- Add
set_cmix_id Call to the Staking pallet. e3677d7
- Migration to fix community Sale distribution vesting schedules. 168d503, 8e4a0cb
- Add
set_vesting Call to the Claims pallet. 12b14db, aa51c3a
- Add
admin_set_vesting Call to the Vesting pallet. 61bd930, 5733619
- Remove duplicate balance deposit event. b07d9f5
Add set_cmix_id Call to the Staking pallet
Issue
There are multiple node operators from BetaNet which are actively nominating in MainNet, while maintaining their nodes in CanaryNet. Now, they have applied to tranche 4 of the transition program, and, if accepted, they will need to set a fresh MainNet cmix id on their stash account, otherwise they can't become active validators. This is currently not possible and would result in many operators needing to fully unbond and wait 28 eras (days) in order to join the network.
Solution
The implementation of a new set_cmix_id Call allows stash accounts that don't have a cmix id to set one without needing to unbond and wait 28 eras. However, if a stash account already has a cmix id it still can't change it using this Call and needs to fully unbond. This means that node operators still need to take special care when first setting their cmix id and ensuring the cmix private keys and certificates are properly backed up.
Migration to fix community Sale distribution vesting schedules
Issue
In the latest community Sale, distributions are made directly in native xx coins using the XXPublic pallet, which holds coins allocated for sales. The team handles the distributions by calling a function on this pallet with a list of coin transfers, each with a destination, amount and vesting schedule. Due to an administration error, the vesting schedule used in these transfers is incorrect: coins are being locked with a 1 year linear vest starting from 14 days after MainNet launch (end of the sale), when they should be in a 1 year lock instead.
Solution
We have implemented custom migration logic, that modifies the affected vesting schedules directly from on-chain storage, and that is executed with the runtime upgrade. The incorrect vesting schedules are deterministic, since they all have the same starting block of 201600 and are uniquely identified, since there aren't any other schedules with this starting block. This way, the migration simply reads all the Vesting storage, loops through all vesting schedules per account, and if the starting block matches the target one, modifies that schedule to the format (lock, lock, new_starting_block), where new_starting_block is 14+365 days, i.e., 5457600. This migration has been tested against MainNet using the try-runtime feature offered by Substrate.
Add set_vesting Call to the Claims pallet
Issue
When the Betanet Staking Rewards program was accepted and enacted, all the existing claims were automatically applied the default 6 month vesting option, with the reward value being added to the claim value, and the 6 month linear vesting schedule added. However, due to a bug in this part of the logic, the principal value used to calculate the vesting lock was already increased by the reward amount. This resulted in a vesting schedule being applied to 0.8*(principal+reward)+reward = 0.8*principal + 1.8*reward instead of 0.8*principal + reward. This bug affects all the existing claims at the time of the enactment of the program (block 432000).
Solution
In order to fix the incorrect vesting schedules, a temporary set_vesting Call was added to the Claims pallet, that will allow the team to directly modify the vesting of leftover claims. The data for each vesting schedule correction will be publicly posted by the team in a newer version of the genesis block spreadsheet, which will allow everyone to audit the changes before they are made. Once the vesting schedules are fixed, the set_vesting Call will be removed from the Claims pallet in a future runtime upgrade.
Add admin_set_vesting Call to the Vesting pallet
Issue
While investigating the previous issue, it became apparent that the logic for vesting schedules computation in Betanet Staking Rewards is incorrect for some situations, where existing locks on coins end while the rewards vesting period is ongoing. This creates an unfair advantage to some accounts that can have their rewards and the required principal vest end faster than expected. Furthermore, any leftover claims that are claimed after the enactment of the program (block 432000) and before the above fix is applied, will still have the incorrect vesting schedule present in the xx network account that was funded by the claim.
Solution
In order to fix all incorrect vesting schedules, a temporary admin_set_vesting Call was added to the Vesting pallet, that will allow the team to directly modify Vesting storage. As with the solution above, the data for any vesting schedule fixes will be posted in a spreadsheet for auditing by the community. Once all vesting schedules in the system are fixed, the admin_set_vesting Call will be removed from the Vesting pallet in a future runtime upgrade.
Remove duplicate balance deposit event
Issue
Whenever an extrinsic is executed, 20% of the fee is deposited into the account of the block author. This logic is implemented at the top-level of the Runtime, and it includes a Deposit event. A substrate change in paritytech/substrate#9425 added missing Deposit and Withdraw events to the Balances pallet, which results in the aforementioned Deposit event for extrinsic fees being duplicate.
Solution
The Deposit event was removed from the Author OnUnbalanced implementation that handles extrinsic fees.
Source code(tar.gz)
Source code(zip)
xxnetwork-chain(106.00 MB)
xxnetwork_runtime-201.compact.compressed.wasm(815.10 KB)
6 Jun 23, 2023
7.7k Dec 30, 2022
4 Mar 30, 2022
1 Jan 8, 2022
256 Dec 26, 2022
11 Dec 29, 2022
52 Dec 27, 2022
1 Oct 19, 2021
0 Nov 6, 2021
16 Nov 29, 2022
55 Dec 15, 2022
6 Dec 20, 2022
12 Aug 28, 2022
243 Dec 16, 2022
10 Apr 2, 2023
10 Jun 16, 2022