TL;DR
The Astar Foundation is proposing to sunset WASM (ink!) smart contracts across Shibuya, Shiden, and Astar. The first step, freezing new WASM contract uploads and instantiation, is already in place on Shibuya and ships for Astar in runtime-2207; existing contracts keep running and user funds stay in user wallets and are not affected. We will work directly with the developers affected throughout the transition.
Background
Three points make this the right time to act.
First, the technology no longer has an upstream future. The ink! language has been discontinued by its maintainers, and pallet_contracts is now legacy upstream. Continuing to accept new WASM deployments would commit Astar to maintaining a stack that no longer receives upstream development.
Second, and the main reason for acting now: an unmaintained contract stack is a security liability that grows over time. With ink! discontinued and pallet_contracts no longer maintained upstream, any vulnerability discovered from here on has no upstream fix. Astar would have to patch, alone, a complex stack it does not own. That risk is not static, it is rising. The cost of finding vulnerabilities in existing code is falling sharply as automated and AI-assisted auditing tools mature, and legacy, low-attention code is exactly the kind of target they surface first. Freezing new deployments stops the surface from growing; removing the pallet once contracts are offboarded removes that attack surface entirely. For a network that secures user value, carrying an unmaintained, unused contract pallet is a risk worth retiring rather than monitoring indefinitely.
Third, active WASM development on Astar has wound down. We reviewed contract activity across both networks:
| Astar | Shiden | |
|---|---|---|
| Live contracts | 305 | 923 |
| All-time unique callers | 3,101 | 245 |
| On-chain storage | ~1.57 MB | ~517 KB |
| Storage deposits | ~22,153 ASTR | ~0.022 SDN |
| Last deployment | Nov 2025 | Jul 2025 |
Recent onchain activity is limited, and the projects still relying on WASM are few and identifiable. That makes this a good moment to retire the stack in an orderly way, in coordination with the developers involved, rather than leaving a discontinued technology in place indefinitely.
This also keeps the contract surface aligned with where the ecosystem is building. New builder activity on Astar runs on EVM, and the ecosystem’s direction is toward financial products. Maintaining a discontinued contract stack alongside that direction adds cost without adding usage.
What is changing today
Runtime-2207 disables new WASM (ink!) contract uploads and instantiation on both Astar and Shiden. This is step one of the sunset and requires no migration. Full details are in the runtime-2207 release notes.
What this does:
- No new WASM (ink!) contracts can be uploaded or instantiated after activation.
- Existing WASM contracts can no longer be upgraded; their deployed code is frozen as-is.
What this does not do:
- Existing WASM contracts continue to execute, hold state, and accept calls.
- EVM contracts, EVM precompiles, and direct extrinsic interactions are unaffected.
- No user funds move or are locked. Storage deposits remain attributed to their original deployers.
The full sunset plan
The sunset is staged so that nothing irreversible happens before the developers on WASM have been contacted and given a real window to act. The Astar removal steps are separate governance actions, each with its own discussion and onchain artifacts.
- Freeze new deployments. Stop new WASM uploads and instantiations via runtime upgrade. No migration needed; existing contracts are unaffected. This is already in place on Shibuya and ships for both Astar and Shiden in runtime-2207.
- Work with the developers (now, in parallel). Contact the teams with live WASM contracts on Astar and Shiden, walk them through the timeline, and give them a 3-month (90-day) window to migrate their projects to EVM smart contracts and self-terminate their WASM contracts. We have already identified the active projects, including the Lucky Finance lottery. Voluntary termination is the cleanest path and is what allows storage deposits to be returned in full.
- Remove the contracts pallet on Shibuya first (testnet). As the testnet, Shibuya carries no real dApps or storage deposits, so its pallet removal goes first and validates the full removal process at no risk to users or funds.
- Remove on Shiden, via sudo call. Shiden’s storage deposits are negligible (~0.022 SDN). Unregister affected contracts from dApp staking if applicable, return storage deposits to deployers, and remove the contracts pallet.
- Remove on Astar after Shiden is clean, via referendum. Run the same process on Astar, including returning the larger storage deposits (approximately 22,153 ASTR) to deployers when contracts are terminated properly, then remove the pallet through an onchain governance vote. We are targeting proposing this removal around September 2026, after the 3-month migration window closes and Shiden is confirmed clean.
- Optional cleanup (later, low priority). Remove leftover WASM references in primitives, documentation, and tooling. No user impact.
Impact for builders and users
Developers currently on WASM.
You have a 3-month (90-day) window to migrate your projects to EVM smart contracts and self-terminate your WASM contracts. We will reach out directly and work with you through the transition; you do not need to navigate this alone. Self-terminating within the window is what allows your storage deposits to be returned in full. We are targeting proposing the Astar contracts-pallet removal around September 2026, so the window is your runway to migrate before then. If you operate or depend on a live WASM contract, reach us by replying on this thread or opening a ticket on the Astar Discord, so we account for it before proposing pallet removal.
Users of WASM dApps.
Your funds are held in your own wallet, not locked in these contracts, so they are not at risk. During the offboarding window the dApps keep working; after the relevant pallet is removed, what goes away is access to those apps as onchain smart-contract experiences, not your tokens. There is no action you need to take to protect your funds.
New builders.
New WASM (ink!) deployments are no longer possible as of runtime-2207. Build on EVM instead; EVM is unaffected by this process and is where new development on Astar already happens.
EVM builders and users.
No impact. EVM contracts, precompiles, and direct extrinsic interactions continue to work exactly as before.
FAQ
Are user funds at risk?
No. User funds stay in user wallets throughout. The freeze and every later step preserve existing state; nothing in this process moves or locks user balances.
Can existing WASM contracts still be called?
Yes. Until the pallet-removal steps, existing WASM contracts continue to execute, hold state, and respond to calls. They can no longer be upgraded, however; the freeze on uploads and instantiation means their deployed code is fixed as-is.
Why remove the pallet instead of just freezing it?
Freezing stops new contracts, but the pallet_contracts code stays in the runtime as an unmaintained attack surface. Because ink! and the pallet are no longer maintained upstream, any future vulnerability would have no upstream fix and Astar would have to patch it alone. As AI-assisted tooling makes vulnerabilities in legacy code cheaper to find, the safest long-term outcome is to remove the unused stack entirely once contracts are offboarded, rather than carry and monitor it indefinitely.
Can I deploy a new WASM (ink!) contract?
No. As of runtime-2207, new WASM uploads and instantiation are disabled on Astar and Shiden. Use EVM for new contract deployments.
Does this affect EVM?
No. EVM contracts, EVM precompiles, and direct extrinsic interactions are unaffected at every step.
What are the approximately 22,153 ASTR mentioned?
They are storage deposits paid by contract deployers when their contracts were deployed; they are not user funds. They are returned to the deployers as part of the sunset, provided the contracts are properly terminated before the pallet is removed.
Why this order: Shibuya, then Shiden, then Astar?
Shibuya is the testnet and carries no real dApps or value, so removing its pallet first validates the process at no risk. Shiden follows, with a far smaller deposit and state footprint than Astar. Astar, which holds the largest deposits, comes last, once the process is proven on both.
How long do I have to migrate?
A 3-month (90-day) window to migrate your project to EVM smart contracts and self-terminate your WASM contracts. We are targeting proposing the Astar contracts-pallet removal around September 2026, after the window closes and Shiden is clean.
I have a live WASM contract. What should I do?
If you want to keep operating your project, start migrating it to EVM smart contracts now; WASM will not be supported after the pallet is removed. Reach us by replying on this thread or opening a ticket on the Astar Discord so we can coordinate with you directly and support the migration. We have identified the active projects, but if we have missed one we want to account for it before proposing pallet removal.
Astar Foundation 
