Written by Helena Markou
Polygon has published a detailed postmortem-style explanation of the Austin and Kyoto hard forks, two coordinated upgrades across its proof-of-stake clients that addressed security and liveness risks. The August 27 disclosure says the fixes were first rolled out privately, validated on the Amoy testnet and then activated on mainnet before the vulnerabilities were publicly described. Polygon says neither issue caused a mainnet disruption, framing the releases as proactive remediation rather than a response to a known exploit.
That sequence is notable in a public blockchain. Transparency is essential to independent review, but releasing detailed exploit paths before a sufficient share of validators has upgraded can create its own risk. Polygon’s approach prioritized a protected rollout first and an explanation after the fleet was safe. The trade-off is temporary opacity, but the rationale is understandable when the issues involve resource exhaustion and the ability of a crafted input to impose correlated costs across validators or peers.
Austin is the Bor v2.10.0 hard fork. It added a per-block gas bound for state-sync events associated with L1-to-L2 bridge deposits and removed the TxDependency field from the block wire format. Polygon describes both as denial-of-service paths in block processing. Without a hard gas cap, enough costly state-sync events could make a block expensive to process and transiently stall the chain. Without a size limit, a TxDependency blob could make peers crash while processing an otherwise valid sibling block. The fixes limit the potential for an attacker to turn cheap input construction into expensive node work.
Kyoto is the Heimdall v0.11.0 hard fork and addresses a broader set of validation and consensus-hardening cases. The most severe issue described by Polygon involved deeply nested protobuf Any messages. A crafted transaction could force substantial decode work across the validator set; Kyoto adds a byte-level prescan and rejects transactions beyond a nesting threshold at both mempool admission and the consensus path. The update also caps fee-coin counts, normalizes a checkpoint signature recovery byte, hardens milestone voting and replay-key handling, and makes a future-span failure degrade and retry rather than halt milestone commitment.
The operational takeaway is clear. Austin activated at Polygon mainnet block 91,949,700, while Kyoto activated at Heimdall mainnet height 51,533,000. Polygon states that nodes still running an earlier client beyond those activation points have already forked away from the canonical chain. It describes the updates as ordinary binary upgrades requiring no state migration, genesis change or full resynchronization, but says affected operators need to upgrade and roll back to a pre-fork height so their nodes can catch up.
These fixes also illuminate a common misconception about network security. The absence of a consensus-correctness flaw does not mean the network is safe from material disruption. A resource-exhaustion path can threaten availability, slow finality, increase hardware pressure or create a reliability problem for applications and bridges without allowing an attacker to rewrite history. Liveness and performance are security properties because users depend on timely, consistent execution—not only on the correctness of an eventual ledger state.
For the broader industry, the interesting feature is the detail of the disclosure. Polygon identifies the input shape, the affected processing stage and the new guard in each case. That lets infrastructure teams assess their upgrade posture and lets outside researchers judge whether the mitigation matches the stated risk. The message for node operators is less philosophical: check the client versions and activation heights now. The message for protocol designers is that metering, bounded parsing and idempotent handling are not defensive niceties; they are core consensus-engineering disciplines.
