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 v7.0.0 is the client we support from here, and the only one that can take part in BEEFY later: v6.2.0 has no BEEFY voter.

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

Orderbook balance details and a disclosure on an attempted attack on the chain

5 October 2026

The orderbook stopped in December 2024. We recovered its ledger, the balance of every account as it stood when it stopped, from a validator's database, and verified it against the hash the chain recorded at the time. It is published with this release in masked form, each address shown by its first and last four characters so that no list of addresses is published, together with the 28 deposits made into the orderbook after it stopped.

The full files are held by the team; their SHA256 sums are in the release. How the list was built is public: the tool that reads a validator's database and verifies every entry against the hash the chain recorded is in the repository, merged as PR 18, and any validator whose node was in sync at the halt can run it, get the same root, and confirm the sums.

Do I need to take any steps? No. If you only held tokens in your own wallet, none of this concerns you. If you had a balance on the orderbook when it stopped, or deposited into it afterwards, your line is in the published files, shown by the first and last four characters of your address, and the return comes through governance without any action on your part.

This release also discloses an attempted attack on the chain. In May 2026 an attempt was made to take the pooled user funds the orderbook still held off the chain, using a defect in the retired orderbook settlement module. The attempt failed: the funds could not leave the chain. The Council has since frozen the assets involved, and the module that held the defect is removed in runtime upgrade 392, which goes to a public vote. The chain's consensus and the PDEX token were never at risk, and no user's own wallet was ever reachable. We completed a review of the chain's code before saying anything in public, so that this post could be complete rather than early.

What happens next. The network intends to return every balance in the ledger, and every later deposit, through a governance proposal in the upgrade after 392. The proposal is intended to cover the small amounts lost in the old bridge from the orderbook's own fee account, in the same tokens. It will be published for review before any vote, and each step will be announced here. The recovered funds are on the Polkadex chain. Returning them in their original form on their home chains, USDT and DOT for example, depends on governance on those chains and on the routes available, and will be taken up separately.

There is nothing to claim. No form, no claim site, no transaction to sign. The team will never message you first or ask for your keys. Anyone who does is a scammer.

About these figures. The ledger is published in masked form as recovered from a validator's database and checked against the root the chain recorded at the halt. Totals are rounded. What is returned is set by the governance proposal, which will be published for review before any vote, and that proposal is what counts. If you believe your line is wrong, open an issue in this repository with your address and the reason. This post describes the position as understood on the date above; it is not legal, financial or investment advice, and no statement in it creates an obligation beyond what governance enacts.

Files

• balances.masked.csv: every orderbook balance at the halt on 14 December 2024, 911 accounts, 2,504 rows. Its root is 0x0899feaee1f47b34036109f56c76b5fbd22ec9e339ecc57fa0bcc58f6a2f05c0, the hash the chain recorded for snapshot 694,063.
• post_halt_deposits.masked.csv: the 28 deposits made after the halt, 16 December 2024 to 20 January 2025.
• SHA256SUMS: the SHA256 sums of the two masked files.
• FULL-FILES-SHA256SUMS: the SHA256 sums of the full files held by the team.

1d09388c573bd15c6ce153a0b9087b96370ac8079116840f42a6d83a458afb08  balances.masked.csv
f2a7e84f87907fdcc5d7577030667414070a3c06fe353b4455a648ff8c447560  post_halt_deposits.masked.csv

Full files, held by the team and not published:

bcd6feaca5cb9194ef5a6027670313116e662193d835d9eeab9bc417fe1de390  balances.csv
9ae8b2ae8f8ef5a646bde6608adb96a2bcc9f6784dba90ed879b377d868dc5bf  post_halt_deposits.csv

Each address is shown by its first and last four characters.

• balances.masked.csv: account_ss58_polkadex, asset, asset_id, balance
• post_halt_deposits.masked.csv: account_ss58_polkadex, asset, asset_id, amount, block, date_utc

Some rows show only an asset id. This table gives the token for each:

Asset id	Token
3496813586714279103986568049643838918	USDT
95930534000017180603917534864279132680	DOT
119367686984583275840673742485354142551	DED
339306133874233608313826294843504252047	PINK
222121451965151777636299756141619631150	ASTR
193492391581201937291053139015355410612	PHA
182269558229932594457975666948556356791	GLMR
130314105136721928300689838359167097187	BNC
313524628741076911470961827389955394913	vDOT
188197390862117588552302061289480388608	CUSDT
226557799181424065994173367616174607641	IBTC
32595388462891559990827225517299393930	UNQ (all balances zero)
123, 456, 789, 101112	tDEX, tBRI, ABC, XYZ (test tokens)

How it was checked. Every ledger entry was verified against the on-chain hash as it was read out of the validator database. The tool is public in the polkadex-node repo. Any validator whose node was in sync at the halt can run it on its database and will get the same root and a file whose SHA256 matches the full-file sum above. The later deposits are read from the chain itself: each one is recorded in the orderbook pallet's ingress messages for its block. As a cross check, the custody account's balances at the halt plus these deposits equal its balances just before 28 May, to within a hundredth of a unit, for every token.