ink! Smart Contracts in 2026: What Changed, and Why the Project Ended

ink! is a Rust-based language for writing WebAssembly smart contracts, built by Parity for Substrate chains including Polkadot. It emerged in 2018 to 2019 as an embedded domain-specific language that lets developers write contracts using ordinary Rust, tagged with attribute macros such as #[ink::contract]. We first wrote about its rough edges in 2021. Since then, the language shipped two major versions, fixed several of those edges, gained a path onto Ethereum-style tooling, and then, in January 2026, stopped being actively maintained at all. This update covers what changed and what the discontinuation means for a team evaluating it today.

What ink! got better at

Three of the five problems we flagged in 2021 are substantially resolved:

• Error handling. Returning Err from a message now reverts all contract state, the behavior Solidity developers expect from a revert. That landed with ink! v5 in March 2024, which Parity built specifically to close gaps found in an OpenZeppelin security review.
• Shared events. Events can now be defined with the #[ink::event] macro outside the #[ink::contract] module, in a separate crate, and reused across multiple contracts, fixed in v5 after years as a tracked GitHub issue.
• Reference implementations. The use-ink/ink-examples repository now carries more than thirty worked examples, from ERC-20 and ERC-721 ports to multisig wallets, cross-contract calls and fuzz testing, a different starting point than the handful of sample contracts available in 2021.

Two of the original five are closer to inherent trade-offs than bugs waiting on a fix. Macro-heavy code is still hard for the Rust compiler to help debug, because #[ink(constructor)] and similar annotations are internal markers expanded at compile time, not real macros a tool can step through. And native cross-contract inheritance is still thin; OpenBrush, built by Brushfam as ink!'s answer to OpenZeppelin, filled that gap with trait-based libraries for standard tokens, though Brushfam itself has since stepped back from Polkadot development, which leaves OpenBrush's own future uncertain.

The bigger shift: ink! v6 moved off WebAssembly

ink! v6 changed how contracts execute, not just how they are written. Contracts now compile to RISC-V and run on PolkaVM through pallet-revive, replacing the wasmi-based Wasm execution every earlier version used. The practical reason this matters: pallet-revive also runs Solidity, through Parity's revive compiler, on the same execution layer. Polkadot's Asset Hub gained this capability on a schedule that slipped slightly, with Kusama's runtime upgrade enacted in late December 2025 and Polkadot's own enactment adjusted to January 27, 2026.

With both languages on one virtual machine, ink! and Solidity contracts can call each other directly, and standard Ethereum tooling, MetaMask, Hardhat, Foundry and ethers.js, works against Polkadot's Asset Hub without the workarounds earlier EVM-compatibility layers needed. v6 also dropped the old call_runtime chain-extension mechanism; the replacement path for calling into runtime functionality is precompile contracts rather than a custom extension per chain.

Then, the same week, ink! was discontinued

On January 27, 2026, the group of developers stewarding ink!, calling itself the ink! Alliance, announced that development had stopped. The timeline behind it: between September and December 2025, the Alliance kept v6 aligned with pallet-revive and the Polkadot SDK without pay, while three funding proposals to Polkadot's on-chain treasury (referenda 1760, 1773 and 1796) were rejected despite shrinking in scope each time. In January 2026, the Web3 Foundation and Parity Technologies confirmed they could not find a strategic case for funding ink! going forward. The announcement calls this a formal deprioritization of ink! as an official Polkadot initiative, not a hand-off to a new maintainer.

The repositories stay public, but issue and pull request creation is locked. For teams with contracts already in production, nothing breaks overnight; for anyone planning new work, the announcement itself states the options plainly: use the low-level Rust API of pallet-revive directly, which the team does not recommend for general use, or rewrite in Solidity, which now runs on the same chains ink! targets. A community member has floated an unofficial simplified SDK called wrevive as a possible third path, but it has no official backing and no production track record as of this writing.

Astar, the chain that hosted most ink! contracts, is sunsetting them

Astar Network, the Polkadot parachain that carried the largest share of live ink! dApps, voted on June 12, 2026 (referendum for runtime-2207) to freeze new WASM contract uploads and instantiation, starting on its Shibuya testnet and then its own chain. Astar's own reasoning tracks the discontinuation directly: with ink! stopped and the underlying pallet_contracts module now legacy upstream, any future vulnerability in that stack has no upstream fix, and Astar does not want to patch a complex runtime module alone. Contracts already deployed keep running and user funds are unaffected, but no new WASM or ink! contract can launch on Astar going forward.

That is the clearest signal yet of where ink!'s remaining production usage is heading: not a sudden shutdown, but the one chain that hosted most of it closing the door to new deployments while directing builders toward Solidity on pallet-revive instead.

ink! vs. Solidity, as it stands now

• Execution: both now run on the same PolkaVM/pallet-revive layer on Polkadot's Asset Hub, so the old Wasm-versus-EVM split no longer separates them technically.
• Tooling: Solidity gets MetaMask, Hardhat, Foundry and ethers.js without workarounds; ink! tooling is whatever existed when development stopped in January 2026.
• Maintenance: Solidity on pallet-revive is Parity's actively funded path; ink! receives no further fixes, and its main contract-standards library, OpenBrush, lost its primary maintainer when Brushfam stepped back from Polkadot.
• Where it still runs: contracts already deployed on Astar and other WASM-enabled chains keep working, but Astar itself has frozen new WASM deployments as of mid-2026.

What this means if you are choosing a language today

For a new Polkadot or Substrate-based project starting now, Solidity on pallet-revive is the supported path: it has Parity's own tooling investment, standard Ethereum developer tooling, and cross-calling into any ink! contracts already deployed. ink! remains usable for contracts already live and for teams who specifically want Rust's type system and testing model over Solidity's, but it carries no bug fixes, no security patches and no roadmap past whatever v6 shipped with. That is a materially different risk profile than it had in 2021, when the issues were rough edges in an actively developed language rather than the absence of a maintainer.

4IRE builds on both Substrate and Solidity, including migrations between the two. If you are weighing a new contract on Polkadot or deciding whether an existing ink! codebase needs a rewrite, our smart contract development team can walk through the trade-off for your specific contracts.