Release v7.0.0

Polkadex node v7.0.0

The first packaged release of the Polkadex node, built on polkadot-sdk stable2512.

Files

File	What it is
polkadex-node_7.0.0-1_amd64.deb	Package for Ubuntu 22.04 or later and Debian 12
polkadex-node-7.0.0-1.x86_64.rpm	Package for Rocky Linux and RHEL 9
polkadex-node	The node binary on its own
customSpecRaw.json	Mainnet chain spec
SHA256SUMS	Checksums of the four files

Check them first with sha256sum -c SHA256SUMS. The binary needs glibc 2.34 or newer and reports polkadex-node 7.0.0-<commit>.

Install

sudo apt install ./polkadex-node_7.0.0-1_amd64.deb      # Ubuntu, Debian
sudo dnf install ./polkadex-node-7.0.0-1.x86_64.rpm     # Rocky, RHEL
sudo $EDITOR /etc/polkadex/node.env                     # NODE_NAME; VALIDATOR_FLAG="--validator" for a validator
sudo systemctl enable --now polkadex-node
journalctl -u polkadex-node -f

The package installs a polkadex-node service that runs as the polkadex user, reads its settings from /etc/polkadex/node.env and keeps chain data in /var/lib/polkadex. It is installed disabled, so nothing runs until you enable it. Later package upgrades restart a running service onto the new binary and leave a stopped one stopped. Removing the package keeps the chain data.

Every time the node stops, its last log line is an error: Essential task `txpool-background` failed. Shutting down service. This is expected during shutdown and can be ignored.

Already running a validator? Follow docs/migrate-to-packaged-node.md to move your keystore, node key and database onto the package. Never run the old and the new node at the same time: they hold the same session keys, and double-signing is slashed.

Do I have to upgrade?

Yes. Please upgrade now, while the 392 runtime upgrade goes through governance, and rotate your session keys once after it enacts (see below).

The 392 runtime also runs on older clients, but the next step does not. The Hyperbridge connection needs BEEFY finality, and only this client takes part in BEEFY: v6.2.0 has no BEEFY voter. BEEFY only works once more than two thirds of validators run this client with real BEEFY keys, which the rotation after 392 provides.

This is also the first release binary that runs on Rocky Linux 9; the v6.2.0 release binary does not.

Runtime 392

The 392 runtime upgrade will be proposed through governance with this exact file: blake2_256 0xccaf34613316e742db4cb844a55c5750148139f0aa181d84f986d12fbe9c0273 (sha256 eda7b6a5ec43e82f6c93be9ba519dfcf94048447f505aa78fb91b50972c6c768). Check the hash in the referendum before you vote. What it changes on chain: council elections keep 5 seats, transaction fees keep going 100% to the treasury, the locks left by the retired rewards and PDEX migration modules are released (1,686 accounts, about 724k PDEX), and four old treasury proposal bonds are refunded.

Validators: after the spec 392 upgrade enacts

1. Rotate your session keys once. Run author_rotateKeys on your node and submit the result with session.setKeys, with 0x as proof.
2. Sign setKeys with your stash account. From 392 on, a setKeys signed by a separate controller account succeeds but does not change your validator's keys.
3. Keep the old keys until the new ones are active. New keys take effect two session boundaries later, 4 to 8 hours on mainnet. Your current keys keep working until then, so there is no gap.
4. Expect one error line at the upgrade block, starting with Corrupted state at and followed by the System::Events key as bytes. It is harmless and does not repeat.
5. Check your bond is still at least 100 PDEX. If the switch to holds left your active bond below the 100 PDEX minimum (most validators affected are short by under 1 PDEX), send the shortfall plus about 1 PDEX for fees to your stash and sign staking.bondExtra(shortfall) with it. Until then, changing your validator settings and unbonding fail.

Details are in docs/release-procedures.md, procedure 6.

Stakers

After 392, bonded PDEX is held instead of locked: wallets show it as reserved, and your total balance does not change. A hold must leave 1 PDEX free. If your stash has less than its bond plus 1 PDEX free, it keeps bonded only what it can hold; the rest stays in your stash, unbonded. Right after the upgrade the team switches every such stash, at no cost to you, so payouts keep working. Anyone can also switch a stash with staking.migrateCurrency(stash), from any account; it is free when it succeeds. If your reward destination is the old "Controller" setting, the team rewrites it to the same account, written out; your rewards keep going to the same place.

Wallets, exchanges and other integrations

Spec 392 raises the transaction version from 2 to 3. Refresh the runtime metadata after the upgrade. A transaction signed for the old runtime that is still waiting when the upgrade enacts becomes invalid and is dropped, not executed; sign it again.

• Balances.transfer is removed; use transferAllowDeath or transferKeepAlive.
• A new transaction extension, WeightReclaim, is added at the end of the list. Signers that hard-code the list must add it.
• Paying fees in an asset now encodes the asset as NativeOrWithId.
• Event and error indices change in Balances, Treasury, Identity, Scheduler, Proxy and Staking. Decode events with the new metadata.
• Runtime APIs: Core moves to version 5, and the orderbook and rewards APIs are removed.

Tested

Before this release:

• clean installs on Ubuntu 22.04, Ubuntu 24.04 and Rocky 9
• package upgrades over a running and a stopped service
• a private four-validator network upgraded from 373 to 392 through governance, with validators moved from v6.2.0 onto the .deb and the .rpm while it ran
• a 72 hour soak on a copy of mainnet state, upgraded from 373 to 392 through the mainnet governance path, with validators on v6.2.0 and on this client, session key rotation from the stash, and the staking switch to holds (details and evidence in #22)
• try-runtime of the 392 upgrade against mainnet state
• CI green on the release commit