Learn how censorship resistance works on Polkadot parachains, why collators matter, and how changes to Aura block production can mitigate data-withholding attacks.
Censorship resistance at the parachain level became increasingly important for Polkadot in 2025 as balances, staking, and governance moved from the Relay Chain to Polkadot Hub. This article explains what parachain censorship resistance means, the possible attacks that motivated changes to Aura block production, and what those changes mean for users.
In a blockchain, censorship resistance is the ability of valid transactions to be included eventually, even when some network participants try to exclude them. For instance, say a block producer excludes a transaction from an individual block. Keeping that transaction from being included over time would require sustained censorship, which means enough control over block production to prevent any other from including it. In this context, decentralization matters because more independent block producers make sustained censorship harder.
Polkadot's Relay Chain consensus operates under an honest-majority security model, while its validator set provides safety and finality guarantees. This model provides the Relay Chain with strong safety and liveness properties. Historically, however, parachain block producers (collators) were not responsible for parachain safety in the same way Relay Chain validators are, and hence their honesty was never assumed. They weren't required to stake, and Polkadot couldn't slash them. In other words, parachain-level censorship resistance wasn't a critical vulnerability because collators didn't anchor core security.
That dynamic changed completely when Polkadot migrated core functionalities like staking, balances, and governance from the Relay Chain to system parachains (such as Asset Hub). One of the main advantages of this migration is that executing logic on a parachain is far more cost-effective and scalable.
The migration, however, made existing parachain-level censorship-resistance properties significantly more important. This is because, although the Relay Chain guarantees that parachain blocks do not violate safety rules, it cannot inherently force liveness or stop a malicious collator from filtering out transactions. So if a colluding majority of collators can censor data, they could, for example, systematically censor 'aye' votes and potentially alter the outcome of a governance referendum or manipulate a runtime upgrade.
The solution is based on Aura, the slot-based block-production protocol that Polkadot system parachains use. Aura assigns collators turns to produce parachain blocks according to a deterministic schedule.
The model depends on several explicit assumptions: at least one honest collator, an honest backer (randomly assigned), and a data availability layer robust enough for honest nodes to download missing block data quickly. This design, however, leaves Aura vulnerable to a data-withholding attack that gives malicious collators a timing advantage (simple front-running attacks) without targeted defenses.
Imagine three collators (A, B, and C) assigned to consecutive time slots. If malicious collators A and C want to censor honest collator B, A produces its block, sends it to the relay chain backers, and withholds the data from B. Before B can download A's block from the data availability layer to build the next link in the chain, C can quickly author a block directly on top of A's, skipping B's turn entirely. B gets only a single slot, so its turn passes before it can react.

To neutralize this attack vector, the research team proposed two potential consensus modifications.
Relative Protocol Timeouts. An alternative approach modifies validation checks to enforce a mandatory waiting period based on relative relay-chain block numbers. This approach ties a collator's right to author a block to a relative delay, stripping away a censoring attacker's speed advantage. If an attacker skips an honest collator, the protocol imposes a timeout constraint on the next collator in line. The subsequent node is then barred from publishing a block until a certain number of relay slots pass, giving the honest node a window to reconstruct the missing data. The risk is a "griefing attack," where malicious collators intentionally stall their own blocks right up to the maximum permitted timeout to degrade overall network throughput.
Multi-Slot Collation. Instead of rotating the block production rights every single slot, the schedule now rotates every few slots. This extends the time an honest collator holds authorship rights, eliminating the clock pressure the attack depends on. A collator therefore gets a window to build a small batch of consecutive blocks. If malicious collator A withholds data, that window gives honest collator B plenty of time to fetch A's block from the availability layer and still publish its own block before its window expires.
A minor trade-off is vulnerability to liveness attacks. Such an attack could occur if an adversarial collator simply goes offline during its multi-slot window. Doing so, however, would cost it the block-production rewards associated with those slots.
Although both approaches were technically viable, relative protocol timeouts made it hard to choose delays and, at minimum, would have required keeping records on the Relay Chain. Following RFC-0154, which specifies the slot configuration for Polkadot Hub, the team therefore implemented the multi-slot collation approach. In its simplest form, this uses 24-second collator slots, where each collator produces collations across four consecutive 6-second Relay Chain blocks. The result is a wider window, making it harder to shut out a collator, since it has time to recover before its turn ends.
This infrastructure hardening not only protects systemic governance, since any other parachain can use it too, but also yields major security benefits for everyday DeFi users and network participants across the ecosystem. These properties can reduce the risk of censorship affecting applications in several ways:
Strengthening censorship resistance at the parachain level reduces malicious collators' ability to keep valid activity off-chain. For Polkadot, that became particularly important once balances, staking, and governance moved onto Polkadot Hub. The result is a stronger foundation for applications that depend on transactions reaching the chain, even when some block producers behave adversarially.
Censorship affects every blockchain, and Polkadot treats censorship resistance as a major protocol-level concern rather than a minor detail. So much so that it has developed more specialized designs for specific parachains. What matters most is that this implementation secures elements common across parachains and services, ultimately protecting many applications.
For a deeper technical explanation, watch the video below. In it, Jeffrey Burdges discusses censorship resistance at the Polkadot parachain level, including the role of collators and the attacks the research prevents.