- Two Polygon network upgrades, named Austin and Kyoto, closed denial-of-service and consensus-hardening flaws. The fixes shipped before the flaws were made public.
- They went into Bor and Heimdall, the two pieces of software every Polygon has to run.
- Polygon says neither flaw was ever exploited. That is the project’s own account, reported by Decrypt, and we could not find Polygon’s original write-up to check it against.
Software gets fixed quietly all the time and you never hear about it. Polygon did that with two network upgrades, closing flaws that could have knocked nodes over or set them against each other, and said so afterwards. The order of those two events is the story.
If you hold POL, there was nothing for you to do at any point, and there still isn’t. The people who had to act were validators and node operators, and they acted before anyone outside knew there was a problem. That is the normal shape of this kind of security work rather than a sign something was hidden from you, which is worth knowing before the word “quietly” in a headline does the thinking for you.
The part that is genuinely unverified is the reassurance. Nobody outside the project has confirmed that the flaws went unused.
What a hard fork actually is
A is thousands of computers running the same rulebook and agreeing, block by block, on the same history. Change the rulebook in a way older software won’t accept and you have a : every node operator has to install the new version, and any that don’t get left behind on a chain nobody else recognises.
Most hard forks are boring by design. Coordinated in advance, scheduled for a specific block, and dull if everything goes right. Austin and Kyoto were that sort of upgrade on the surface, with the security content left out of the announcement until later.
Bor and Heimdall, and why there are two
Polygon’s proof-of-stake network splits the job in two. Bor is the execution layer, derived from Ethereum’s Geth client, and it does the work you’d recognise: assembling transactions into blocks and running . Heimdall is the consensus layer, which tracks who the validators are, decides what counts as final, and periodically writes checkpoints back to Ethereum.
Both had to be touched, which tells you the flaws weren’t confined to one corner of the stack. On the classes of bug involved, a denial-of-service flaw generally means an attacker can feed a node something that makes it crash or fall behind, and consensus hardening means reducing the chance that honest nodes end up disagreeing about what happened. Neither needs stolen keys. Both, at scale, can stop a chain producing blocks.
Decrypt’s write-up doesn’t set out the technical detail of either flaw, and without Polygon’s own disclosure we can’t say how close to that outcome the network came.
Why quiet patching is the norm
Announcing a live consensus bug is publishing a recipe. Nodes upgrade at their operators’ pace, not on command, so there is always a window in which a meaningful share of the network is still running the vulnerable version. Say the words out loud during that window and you have handed an attacker instructions plus a list of targets.
Bitcoin Core did the same calculation in 2018. It shipped version 0.16.3 describing the fix as a denial-of-service patch, waited for and node operators to update, and only then confirmed that the same bug could have been used to create coins out of nothing. Ethereum’s Go client team has an established practice along the same lines: security fixes go out inside ordinary-looking releases, with the details following once adoption is high enough.
So the pattern is standard, across the two largest networks in the industry. What varies between projects is the gap, and nothing obliges anyone to keep it short.
What Polygon hasn’t shown
Polygon’s position, as relayed by Decrypt, is that neither flaw was exploited. We could not locate a primary statement from the project, which matters here for a specific reason: “never exploited” is a claim about attacks that didn’t happen, and the only people with the logs to support it are the ones making the claim.
That isn’t an accusation. It is the limit of what anyone reading this can know. An independent post-mortem, or a third-party review of the patched code, would move it from assurance to finding, and neither has appeared.
What to watch
Whether Polygon publishes the technical detail of what Austin and Kyoto fixed, including how long each flaw existed and how many nodes had upgraded before it went public. That document is what turns a quiet patch into a defensible one.
The broader open question is who judges the gap. Client teams currently decide for themselves how long to stay silent, with no published standard and no outside body checking the call. It has worked so far on Bitcoin and Ethereum, largely because the people making those calls are well known and heavily watched. On smaller networks it rests on trust nobody has been asked to earn. More on how the underlying networks work sits in our technology coverage, and price and market detail for the is on the Polygon coin page.