Polygon Labs, the developer behind the Polygon proof-of-stake (PoS) blockchain, has released two critical hard forks to address significant security vulnerabilities found in its network. The company disclosed details about these upgrades—which include the Austin and Kyoto forks—in a newly published forum post, and called on all node operators to update their software or risk being removed from the network consensus.
Kyoto fork strengthens validator security
The most severe flaw was discovered in Heimdall, which is the coordination software used by Polygon validators. Heimdall is responsible for organizing validator activity to secure the network. The vulnerability stemmed from how Heimdall handled transaction data, placing each transaction inside a wrapper called google.protobuf.Any.
This structure allowed attackers to stack multiple nested wrappers inside a single transaction, causing validators to expend excessive computing power to unpack the transaction with little cost to the attacker. Polygon Labs called it “a permissionless way to force costly, correlated work across the whole validator set.”
The Kyoto hard fork upgraded Heimdall to version 0.11.0 and implemented a byte-level pre-scan mechanism that rejects any transaction exceeding a set nesting threshold. This filter is enforced both when transactions enter the mempool and during block proposal, ensuring that only valid transactions are processed efficiently.
ETH
SOL
BSC
ROBINHOOD
USDT
AAPLKyoto adds a byte-level pre-scan that rejects a transaction once its nesting passes a threshold, enforced identically at mempool admission (CheckTx) and on the consensus path (ProcessProposal).
Polygon’s dual checks occur both when a transaction arrives and when validators assemble a new block to confirm.
Mini dictionary: Heimdall is Polygon’s validator orchestration software, essential for coordinating consensus and security in the network’s PoS framework.
Austin fork targets Denial-of-Service risks
The Austin hard fork addressed two denial-of-service vulnerabilities in Bor, Polygon’s transaction execution client. One risk was related to “state-sync events,” which are responsible for processing deposits from Ethereum (Layer 1) to Polygon (Layer 2). These events could have executed unlimited contract code and precompiles per block, as there was previously no cap on gas usage per block.
To prevent this, the Austin fork introduced a strict per-block gas limit on state-sync events.
Another vulnerability involved the TxDependency field, which lacked a maximum size limit. A malicious validator could fill this field with excessive data, potentially crashing every node that tried to process the affected block. The Austin upgrade eliminates the TxDependency field from the communication format entirely, closing off this attack vector.
| Hard fork | Focus area | Main patches | Upgrade version | Mainnet activation point |
|---|---|---|---|---|
| Kyoto | Heimdall (validator coordination) | Nesting limit for transaction wrappers | 0.11.0 | Heimdall height 51,533,000 |
| Austin | Bor (transaction execution) | State-sync block gas cap, TxDependency field removal | 2.10.0 | Bor block 91,949,700 |
Network health and node upgrade requirements
Polygon Labs confirmed that, to the best of its knowledge, none of the security issues were exploited on the mainnet before the upgrades were activated. The required software versions are Bor v2.10.0 for all nodes and Heimdall v0.11.0 for validators and full nodes. Any node running old software has already been separated from the main Polygon chain.
These updates are simple binary upgrades, meaning operators do not need to conduct state migrations, change the genesis file, or perform full resynchronizations.
POL, the token for the Polygon ecosystem, traded at $0.09, falling 9.3% in the past 24 hours. However, its price remained stronger over the 30-day period, rising 25.8% based on CoinGecko data.
Polygon previously experienced a mainnet outage in July, when Heimdall V2 went offline for approximately one hour. Polygon Labs continues to respond to such challenges and implement network improvements as needed.
