TL;DR
Astar maintains HRMP channels with multiple Polkadot parachains. Five of them have gone dormant or never built meaningful flow. We propose closing them in both directions to reduce the risk of misuse, lower the ongoing maintenance burden, and tighten Astar’s XCM trust surface. The list: Sora, Clover, Darwinia, Interlay, and Composable.
Background
Every open HRMP channel is a live trust path. It accepts inbound XCM messages from the counterparty and has to be kept compatible across XCM version upgrades, reanchoring changes, and runtime migrations. As long as a channel is open, the counterparty’s operational health is part of Astar’s threat model.
That is fine for active integrations. It is not fine for channels that no longer carry meaningful traffic. Dormant channels age along with the parachain on the other end: validator sets thin out, teams disband, key custody assumptions weaken. The channel keeps accepting messages anyway.
A periodic review of low-traffic channels is healthy housekeeping. We have looked at outbound and inbound flows for every Astar channel on Subscan and identified five that no longer justify staying open.
Proposal
Close the following HRMP channels in both directions (10 closures total). Last observed transaction per Subscan, UTC:
| Counterparty | ParaID | Last activity |
|---|---|---|
| Sora | 2025 | 2025-11-16 |
| Clover | 2002 | 2023-02-20 |
| Darwinia | 2046 | 2023-03-07 |
| Interlay | 2032 | 2026-04-26 |
| Composable | 2019 | 2024-05-17 |
Sources: Subscan XCM channels.
Preimage hash:
0xaa25cc3da11962abac0039854d33a312db6019a523eb4816a4fcc9b987ff1965
Extrinsic call data:
0x3300030100031400040000000002286bee130000000002286bee0006000700bca06501420d03009d011a02283c02d6070000d20700003c02d2070000d60700003c02d6070000e90700003c02e9070000d60700003c02d6070000fe0700003c02fe070000d60700003c02d6070000f00700003c02f0070000d60700003c02d6070000e30700003c02e3070000d6070000140d0100000100591f
Rationale
Three of the five counterparties stopped exchanging XCM messages with Astar in 2023 or 2024 (Clover, Darwinia, Composable). Sora’s last message is from late 2025. None have rebuilt activity since.
The case for closing them is not about reclaiming resources. It is about removing trust paths we no longer use:
-
Misuse prevention. An open channel into a parachain whose team, validators, or governance has gone quiet is a latent risk. If the counterparty is ever compromised, the XCM path into Astar is already there.
-
Maintenance reduction. Every runtime upgrade and XCM version bump has to account for every open channel. Removing inactive ones shrinks the matrix engineering has to validate against.
-
Security posture. Astar’s XCM trust surface should match its active integrations, not its historical ones.
Closure is reversible. If any of these counterparties becomes relevant again, a future referendum can reopen the channel.
Interlay is the borderline case in this batch. It shows a more recent transaction (2026-04-26), but volume has been thin and the integration that originally justified the channel has wound down. We are surfacing it explicitly so the community can flag any remaining dependency before the referendum goes on-chain.
Impact
-
Users: anyone holding assets bridged through these channels should withdraw or reroute before closure executes. Closing a channel cuts the XCM path; it does not affect assets already settled on Astar or on the counterparty chain.
-
dApps and integrators: any application that still calls into these channels will need to migrate. We will publish a final cutover notice once the referendum is scheduled.
-
Runtime and security: fewer active channels to maintain through future upgrades, and a tighter set of trusted counterparties on the XCM side.
Closing a channel does not delete history and does not block reopening later.
Next steps
-
Community discussion on this thread.
-
Onchain referendum submission using the preimage above.
-
Final reminder with a clear cutover date before execution, so any residual users have time to act.
Gaius_sama, Astar Foundation 