Polygon fixed a validator-stalling bug in two hard forks before saying what it was
The Austin and Kyoto upgrades reached mainnet before Polygon described what they repaired, a sequence that is standard practice for client teams and still leaves any operator on old binaries reading a public bug report from off consensus.
The Investor · Invest desk
What happened
- Polygon says the Austin and Kyoto hard forks were deployed privately and tested before mainnet activation, with the vulnerabilities they fixed disclosed only afterwards.
- Austin lifted the Bor execution client to v2.10.0 at mainnet block 91,949,700 and introduced per-block gas bounds on L1-to-L2 state-sync events that had been effectively un-metered.
- Kyoto lifted the Heimdall consensus client to v0.11.0 at block 51,533,000, patching byte-level nesting and signature validation flaws in its handling of protobuf Any messages.
- The most severe flaw sat in Heimdall, where a specially crafted transaction could force validators into excessive processing work and potentially disrupt the network.
- Polygon says none of the vulnerabilities were observed being exploited on mainnet, and that the fixes went out proactively before any details were made public.
Why it matters
- Who's exposed exposure Operators still on pre-fork binaries are the ones the disclosure reaches last and hurts most: they sit outside canonical consensus while a written description of a crash path is now in circulation.
- What it limits constraint The deploy-then-tell option existed only because nothing had to migrate; a fix requiring genesis or state changes would have to be negotiated in the open, which caps how often this route is available.
- What doesn't add up contradiction The two accounts of when the forum post landed relative to the August 29 activation cannot both be right, and until that is resolved nobody outside Polygon can measure the embargo they are being asked to accept.
- Who has to decide decision Validator operators mid-way through the POL migration and staking reform now have to fund an unplanned upgrade cycle out of the same attention budget.
Next story · Build · 9h ago
Zenity Labs: one prompt to a public AgentCore agent could return temporary credentials tied to a default role not scoped to that agentConfirmed3 publishers
The load-bearing term here is scope. Both forks were binary-only, with no genesis file changes and no state migration, and the chain state itself stayed intact [14], which is what made the private route available at all: a change that touches state has to be socialised weeks ahead because operators must plan for it, and planning leaks, while a change that arrives as a point release can travel as housekeeping. The two activation heights sit about 40.4 million blocks apart, 91,949,700 on the execution client against 51,533,000 on the consensus client [18], which is a reminder that this was two separately timed switches on two counters rather than one moment, and both had to land without the reason being obvious. Polygon reports no mainnet disruption during either activation, and says both were validated on the Amoy testnet first [15].
Where the record goes soft is the sequence. Cointelegraph dates the disclosure from Polygon Labs' Validators Support Team to a Thursday [10] and says the forks were deployed privately and tested before mainnet activation and publication [3]; Crypto Briefing places the community forum write-up two days off the August 29 activation and then says the disclosure was timed to follow successful activation rather than precede it [20]. Those do not reconcile into a single window, and the width of that window is the one figure an outsider would need to judge the embargo, which neither account supplies.
The allocation cost is quieter. Crypto Briefing notes Polygon activated the Ithaca fork in July 2026 for liveness and payment reliability [16], and that the validator and staker community is simultaneously absorbing the MATIC-to-POL move, staking reform discussions and a liquid staking token called sPOL [21]; Bor v2.10.0 is now required for every PoS node and Heimdall v0.11.0 for validators and full nodes [9], so the hours a stranded operator spends rolling back and resyncing [8] are hours not spent on the economics of that transition.
Price is not adjudicating any of this. POL traded near $0.10, down about 4% on the week, up 44% on the month and up 2.3% year to date on CoinGecko numbers [17], which means that before the last month the token was down roughly 29% for the year, since 1.023 divided by 1.44 is 0.711 [19]. A disclosure with no observed exploitation on mainnet [13] is not what moved that, in either direction.
This is probably wrong, but the governance question I would press is not whether to patch quietly, because the counter-thesis is mostly right: patch privately, test, activate, then publish is the order client teams are taught, and inverting it hands out a denial-of-service recipe while stake is still on old binaries. The question is what the "need to know" set looks like when the fix only works if every validator runs it. What would settle the argument is the stake-weighted share already upgraded at each activation height. At 99% the residual exposure is a rounding error; at 85%, Polygon published a description of a crash path [12] for a meaningful slice of a network whose laggards were already outside canonical consensus [8]. That number sits with Polygon, and it is the one I would want published.
What to watch
- Whether Polygon publishes the stake-weighted share of validators that had upgraded before each activation height.
- Whether a severity rating and a dated disclosure timeline for Austin and Kyoto appear on the community forum.
- Whether the next Polygon fork that requires a state migration gets the same deploy-then-disclose treatment, or cannot.
Information, not investment advice. This story is general information about companies and markets, drawn from cited reporting. It is not a recommendation to buy, sell or hold any security; check the cited sources before acting.
Clarity's read
What the record supports and how the coverage leans. The claims behind it follow.
Reality
- Evidence58
- Adoption65
- Hype gap+16
- Incentives70
- Confidence60
Claim ledger
Ranked by verification strength, evidence, and original report placement.
- [1]
Polygon Labs disclosed a pair of security vulnerabilities that were quietly patched across two hard forks before the network said anything publicly.
- [2]
The fixes landed in the Austin and Kyoto upgrades, which activated on the Polygon proof-of-stake mainnet on August 29.
- [3]
Polygon said the flaws were fixed through the Austin and Kyoto hard forks, which were deployed privately and tested before being activated on mainnet and publicly disclosed.
- [4]
The Austin hard fork upgraded the Bor execution client to v2.10.0, activating at mainnet block 91,949,700.
- [5]
Kyoto upgraded the Heimdall consensus client to v0.11.0, activating at block height 51,533,000.
- [6]
Heimdall had byte-level nesting vulnerabilities in its handling of protobuf Any messages, a serialization format used heavily in the Cosmos SDK stack, where nested message handling errors and signature validation issues could disrupt consensus messaging between validators; Kyoto patched those checks at the byte level.
- [7]
The most severe issue involved Heimdall, where a specially crafted transaction could force validators to perform excessive processing work, potentially disrupting the network.
- [8]
Any validator or node operator still running pre-fork binaries is now operating outside canonical consensus, and Polygon's guidance is to upgrade to Bor v2.10.0 or higher and Heimdall v0.11.0 or higher immediately or follow rollback and resynchronization procedures.
- [9]
Bor v2.10.0 is required for all Polygon PoS nodes, while Heimdall v0.11.0 is required for validators and full nodes, with both upgrades already active on mainnet.
- [10]
The vulnerabilities affected Polygon's Bor and Heimdall clients and included denial-of-service risks, validator resource exhaustion and flaws affecting checkpoint and milestone processing, according to a Thursday disclosure from Polygon Labs' Validators Support Team.
- [11]
L1-to-L2 state-sync events on Bor were effectively un-metered, able to consume block resources without the gas accounting that normally limits runaway computation; Austin introduced per-block gas bounds to cap that exposure.
- [12]
The second Bor issue involved unbounded TxDependency data, and without limits on how large that structure could grow, a crafted input could stall block processing or crash connected peers entirely.
- [13]
None of the vulnerabilities were observed being exploited on mainnet, according to Polygon, which said the fixes were deployed proactively before details were made public.
- [14]
Both forks required only binary upgrades, with no genesis file changes, no state migration and no rewriting of historical chain data; validators needed to update software while the chain state remained intact.
- [15]
Polygon reported no mainnet disruption during either activation, and both forks were validated on the Amoy testnet before mainnet deployment.
- [16]
Polygon activated the Ithaca hard fork in July 2026, targeting liveness improvements and payment reliability on the network.
- [17]
POL was trading around $0.10 at the time of writing, down about 4% over the past week, up 44% over the past month and up 2.3% year to date, according to CoinGecko data.
- [18]
The Bor and Heimdall activation heights are 40,416,700 blocks apart, roughly 40.4 million.
- [19]
Before the most recent month, POL was down roughly 29% year to date.
- [20]
Crypto Briefing describes a community forum post detailing the technical fixes as coming two days earlier than the August 29 mainnet activation, and separately states that the community forum disclosure was timed to follow the successful mainnet activation rather than precede it.
- [21]
The shift from MATIC to POL as the native token, combined with ongoing staking reform discussions and the introduction of a liquid staking token called sPOL, means the validator and staker community is absorbing economic and technical changes simultaneously.
Sources
2 independent publishers whose own reporting we read for this story.
- cointelegraph.comPolygon discloses security flaws fixed in recent hard forks
1 article · August 29, 2026
- cryptobriefing.comPolygon discloses security flaws fixed in Austin and Kyoto hard forks
1 article · August 29, 2026
Topics and entities
Topics
- Blockchain client security
- Coordinated Vulnerability Disclosure
- Validator and node operations
- Hard fork upgrade coordination
- Polygon's POL transition
- Cosmos SDK message handling
Entities
- CoinGecko
- Ithaca hard fork
- Cosmos SDK
- Austin hard fork