Polygon Labs issues urgent client upgrade notice following Austin and Kyoto hardforks

Polygon Labs Mandates Client Updates Amid Austin and Kyoto Hard Forks

Austin and Kyoto addressed separate client risks

Polygon Labs announced that any PoS node retaining the pre‑hardfork versions of Bor or Heimdall after the two August activations has effectively left the protocol’s canonical consensus. Stale nodes must upgrade to re‑establish alignment with the network’s accepted historical state.

The company’s security review dated August 27 highlighted client‑compatibility vulnerabilities. Polygon clarified that the mainnet experienced no material disruption caused by the Austin upgrade and presented the proposed changes as proactive mitigations rather than incident responses.

Bor serves as the execution client for Polygon PoS, whereas Heimdall manages consensus and checkpointing. Versions of Bor prior to v2.10.0 became inconsistent once Austin activated at mainnet block 91,949,700—a threshold that now applies universally to all Bor node functions.

Heimdall validators and full nodes require the update to version v0.11.0 after Kyoto triggered at height 51,533,000. The official Heimdall release notes timestamp the mainnet activation to 10:10:31 UTC on August 18.

<hr row omitted – keep only required parts>

Kyoto introduces critical safeguards against resource‑exhaustion attacks

Kyoto’s most severe correction targets deeply nested `google.protobuf.Any` messages. Previously, a malformed transaction crafted by the sender could induce excessive decoding overhead across the entire validator set. By inserting a byte‑level nesting verification at both mempool admission and block‑proposal phases, the hardfork guarantees a predictable cost model.

The same upgrade caps fee‑coin listings before an O(n) validation sweep, allowing Heimdall to integrate support for a single fee‑coin without breaking the consensus safety guarantees.

Additional improvements across Kyoto focus on eliminating idempotency gaps. Checkpoint‑signature recovery bytes are normalized so a legitimate Ethereum signature never fails on the local checkpoint, preventing orphaned anchors. Repeated producer downtime notifications are rendered idempotent, milestone‑range voting ties voters to the signed parent hash, and failed future‑span creations can no longer stall milestone commitment.

Finally, replay permissions for `topup`, `clerk`, and `stake` events are tightened to be injectable, ensuring that distinct layer‑1 inputs cannot silently overwrite one another.

Both hard forks represent straightforward binary upgrades; none involve state migrations or Genesis configuration changes. Nodes that have not yet diverged prior to the relevant block height require no additional synchronization.

Operators operating ahead of the specified height on outdated clients should immediately apply the matching firmware release, optionally revert to a pre‑hardfork baseline if legacy logic proves necessary, and then initiate a synced restart following Polygon’s deployment guidelines.

Source link