We’ve updated our Polkadot infrastructure to polkadot-stable2512-1 (polkadot-v1.21.1), so you can already enjoy the latest fixes and improvements. This patch release brings smoother networking (including more stable WebSockets), better visibility for transaction behavior in edge cases, and a set of runtime upgrades focused on reliability and security. Connect as usual — everything is live and ready for you to use.

1) Improvements for node/client developers 

A. Better insight into “what happened to my transaction?”

A change adds a new experimental metric that tracks every time a transaction shows up as “InBlock” — not just the first time.

Why is that useful?
Sometimes the chain temporarily reorganizes (a fork resolves), and a transaction can appear in more than one block during that process. The new metric helps teams see that behavior clearly, which is useful for monitoring reliability and building better “confidence” signals.

B. More stable WebSocket connections

The node’s peer-to-peer library (litep2p) was upgraded. This brings fixes that specifically improve WebSocket stability, including avoiding failures during a sensitive handshake/negotiation stage.

2) Runtime improvements (changes to chain rules / pallets)

Runtime changes matter because they affect how the chain behaves at the protocol level. Here are the main points, explained simply:

A. “pallet-revive” changes were backported (to avoid a downgrade later)

Polkadot backported changes to pallet-revive so that a future runtime upgrade won’t accidentally feel like a step backward compared to work already done elsewhere.

Keeping features consistent so the next upgrade doesn’t regress.

B. Asset conversion got broader compatibility (V3 → V5 conversions)

Asset versions can differ across systems. This change adds support for converting asset formats (V3 to V5) in a matching step used by localPay.

Assets “translate” between versions more smoothly, so payments and matching work in more cases.

C. A DoS risk was reduced by charging “weight” for heavy operations

Some built-in cryptographic helpers (precompiles like sr25519_verify and ecdsa_to_eth_address) were missing proper “weight charges.”

Why that matters:
If heavy computations are free (or under-priced), attackers can spam them and overload the network.

Expensive actions now have an appropriate cost — making spam attacks harder.

D. Benchmarking fixes (more accurate performance measurement)

There are several changes that improve benchmarking accuracy:

• Removing noisy timing artifacts (“timing leaks”) caused by huge setup operations
  
  
• Making certain weights depend on real parameters (like how many “reserves” are set), not worst-case guesses

Performance measurements become more trustworthy, so fees/limits can be tuned more correctly.

E. Stricter withdrawal validation in asset-conversion payments

Validation logic was updated to only accept a clean success case (instead of permissive “would die / reduced to zero” outcomes) so it matches the strict rules the runtime actually enforces.

Payment checks now match the real rules — fewer edge-case mismatches.

F. Fix for “force_reserve” in pallet-broker (coretime issue)

A bug could cause a parachain to temporarily lose reserved “coretime” for one region due to how sale rotations overwrite unused cores. The fix tracks force-reserved cores properly so they aren’t overwritten.

Reserved resources won’t accidentally disappear during a rotation cycle.

G. BlockRatioFee no longer depends on pallet-revive

This is a “cleanup” improvement: a fee formula type can now be used without requiring pallet-revive just for type discovery.

More modular runtime building — fewer unnecessary dependencies.

E. New “pallet-dap” foundation (Dynamic Allocation Pool) and fewer burns

A new pallet (pallet-dap) was introduced as a foundation for routing certain funds (like slashes) into a buffer account instead of burning them.
Additionally, treasury “burns” were disabled in some runtimes by setting the burn parameter to zero — meaning funds aren’t automatically destroyed at the end of spend periods.

Less automatic token burning in those environments; slashed funds can be redirected rather than erased (depending on configuration).

3) User-facing runtime changes

A. “Unslashable nominators” with faster unbonding (configurable)

Nominators can now be configured as “unslashable,” and if they are, they can use a faster unbonding time (recommended: 2 eras).

 Some nominators may be allowed to unstake faster, if the chain config enables it.

B. Multi-asset bounties added to Westend Asset Hub testnet runtime

Multi-asset bounties become available in the Westend Asset Hub runtime (testnet context).

 On that testnet environment, bounties can work with more than one asset type.

Final takeaway

This patch release is a “small but important” update:

• more stable networking (especially WebSockets),
  
• better transaction tracking during reorgs,
  
• runtime fixes that reduce attack surface and improve correctness,
  
• some staking/user improvements depending on chain config.
  
  

If you’re already on stable2512, upgrading to stable2512-1 (polkadot-v1.21.1) is the sensible maintenance step.