Author
Ahmed Barakat
Author
Share
Polygon Crypto deployed two coordinated hard forks, Austin on Bor v2.10.0 and Kyoto on Heimdall v0.11.0, to close denial-of-service, resource-exhaustion and consensus-hardening risks across its Polygon PoS client stack. Both upgrades were rolled out privately and validated on the Amoy testnet before mainnet activation, according to a Polygon forum post published August 27.
No mainnet disruption was observed from the vulnerabilities Austin addressed, and both forks were already active on Amoy and mainnet by the time the disclosure went public.
The sequencing matters: Polygon fixed the issues, confirmed the fleet was safe, then explained what had been broken – not the other way around.
Polygon Crypto: What Austin and Kyoto Actually Fixed
Austin closed two Bor block-processing DoS paths. State-sync events, which handle L1-to-L2 bridge deposits, execute contract code and precompiles just like ordinary transactions, but their gas consumption previously wasn’t metered against a hard per-block cap.
A block carrying enough state-sync events, or one especially expensive one, could make processing slow enough to transiently stall the chain. Austin added an explicit per-block gas bound to close that gap.
The second Austin fix removed Bor’s TxDependency wire field entirely. The field was a parallel-execution hint with no size limit, meaning a block producer could stuff an arbitrarily large blob into an otherwise valid sibling block and crash any peer that tried to process it.
Since parallel execution doesn’t need peers to trust a producer’s hint to function correctly, removing the field cost nothing downstream.
Kyoto’s most severe fix targeted deeply nested google.protobuf.Any fields in Heimdall transactions. Without a cap, a single cheaply-crafted transaction could force every validator to perform disproportionately expensive decode work simultaneously, a permissionless way to impose costly, correlated load across the entire validator set.
Kyoto added a byte-level pre-scan enforced identically at mempool admission and on the consensus path, so a transaction can’t slip through one check and get rejected by the other.
Kyoto also bundled smaller hardening fixes: a cap on fee-coin counts, normalized checkpoint signature recovery bytes, idempotent handling of repeated producer-downtime messages, milestone range votes bound to the signed parent hash, checkpoint-window continuity checks, non-halting future-span creation, and injective replay keys for topup, clerk and stake L1 events.
All of it is inert below the fork height – normal traffic sees no behavioral change. That kind of layered validation hardening echoes broader industry efforts to shore up transaction-processing edge cases before they’re exploited, similar in spirit to protocol-level changes aimed at emerging transaction-security threats elsewhere in the industry.
Make Your Prediction Count With $25 For Free on Kalshi
Why Bor and Heimdall Both Needed Patching
Austin activated at Amoy block 44,120,000 and mainnet block 91,949,700. Kyoto activated at Amoy height 42,252,000 and mainnet height 51,533,000.
Bor handles block execution while Heimdall runs consensus, and Kyoto’s fixes span ABCI, milestone, bor, stake, topup, clerk and bridge processing, meaning the patch touched checkpoint finality, milestone accounting and L1-event replay logic all at once.
Bor v2.10.0 is mandatory for all nodes; Heimdall v0.11.0 is mandatory for all validators and full nodes. Both are plain binary upgrades with no state migration or genesis change required for operators already current.
That’s a distinct case from nodes still running pre-fork binaries past the activation heights: those have already forked off canonical consensus and need to upgrade and roll back to resync, rather than simply updating in place.
Coordinated client upgrades of this kind carry real operational stakes for any high-throughput chain, a dynamic playing out elsewhere as networks weigh state growth and execution risk against upgrade cadence, see the ongoing debate around Ethereum’s Glamsterdam upgrade path.
For Polygon PoS, the takeaway is straightforward: the vulnerabilities were resource-exhaustion and consensus-edge-case risks, not correctness failures, and both were resolved before any exploitation was observed on mainnet.
The Best Traders Around Use It: AI Copy Trading Bots From CryptoHopper