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

Polygon Labs said any Polygon PoS node that stayed on pre-hardfork Bor or Heimdall binaries past two August activation heights has already fallen out of canonical consensus. In practice, the stale node must upgrade and catch up before it can follow the network's accepted history again.

The company's Aug. 27 security review described a client-compatibility consequence. Polygon said it had not observed mainnet disruption from Austin and framed the disclosed changes as proactive fixes.

Bor is Polygon PoS's execution client, while Heimdall handles consensus and checkpointing. Bor versions earlier than v2.10.0 are incompatible after Austin activated at mainnet block 91,949,700, a cutoff that applies to all Bor node roles.

Heimdall validators and full nodes need v0.11.0 after Kyoto activated at height 51,533,000. Polygon's Heimdall release notice dates that mainnet activation to Aug. 18 at 10:10:31 UTC.

Austin and Kyoto addressed separate client risks

Austin capped the gas consumed while Bor processes state-sync events from L1-to-L2 bridge deposits. Those events execute contract code and precompiles, but their gas use was not previously counted against a fixed block-level ceiling.

Enough events, or one sufficiently costly event, could make block processing slow enough to stall the chain transiently.

The second weakness sat in Bor's TxDependency extra-data field, a hint used for parallel execution. Because the producer-supplied field had no size limit, a block producer could place an arbitrarily large blob in an otherwise valid sibling block and crash peers that tried to process it.

Austin removed the field from the wire format, and Polygon classified both weaknesses as resource-exhaustion risks.

The public Bor v2.10.0 release records Austin's mainnet and Amoy activation blocks. GitHub showed v2.10.1 as the latest Bor release when checked Aug. 28, while v2.10.0 or later provides Austin compatibility.

Operationally, one Austin path threatened delayed block processing, while the other could terminate peers receiving a producer's oversized data field.

Kyoto's highest-severity fix targets deeply nested google.protobuf.Any messages. A sender could cheaply construct one transaction that forced every validator to spend heavily on decoding. The hardfork added a byte-level nesting check at both mempool admission and block-proposal processing, keeping those paths consistent.

It separately capped fee-coin lists before an O(n) validation scan, and Heimdall's integration permits one fee coin.

Other Kyoto changes address distinct edge cases. They normalize checkpoint signature recovery bytes so a valid signature cannot fail recovery on Ethereum and stall anchoring, make repeated producer-downtime messages idempotent, bind milestone-range votes to the signed parent hash, and prevent a failed future-span creation from blocking milestone commitment.

Replay keys for topup, clerk, and stake events were also made injective for out-of-range log indexes so distinct layer-1 events cannot silently shadow each other.

Both hardforks are plain binary upgrades with no state migration or genesis change, and nodes that had not diverged require no resync.

Operators already past the relevant height on an older client should install the applicable release, roll back to a pre-hardfork point if needed, and resync under Polygon's guidance.

This content is provided for general informational purposes only and doesn't constitute financial, investment, legal, or tax advice. Any events, rewards, online promotions, or related information mentioned herein should not be considered a recommendation, solicitation, or invitation to purchase, sell, trade, or otherwise deal in any crypto assets. Crypto assets are highly volatile and may result in loss. The availability of WEEX services, products, and related events may vary by region. You are responsible for ensuring that your participation is in accordance with applicable local laws and regulations.