ink! speaks Solidity on PolkaVM

ink! speaks Solidity on PolkaVM

With PolkaVM and pallet-revive on the horizon, we’re not just talking about a faster, more predictable VM for Polkadot, we’re talking about Ethereum-style precompiles, H160 addresses, Solidity contract support, and a developer experience that suddenly feels very familiar to anyone from the EVM world.

So the ink! team did the obvious next thing: they taught ink! to speak Solidity ABI fluently.

Why? Three reasons:

1. pallet-revive is built with Solidity in mind.
2. Interoperability: ink! and Solidity contracts can now call each other directly.
3. Tooling: MetaMask, Hardhat, Foundry, ethers.js all work without hacks.

How ink! learned to speak Solidity

ink! had to rethink how to handle types, encoding, account formats, selectors & constructors, events and errors.

Rust & Solidity types

Rust offers a richer type system than Solidity: enums with fields, generics, and complex composite custom types (see Algebraic Data Types). Solidity does support simpler cases; field-less enums and nested structs, but not the more expressive combinations that Rust allows. To bridge the gap, ink! uses the SolEncode and SolDecode traits to turn familiar Rust types into Solidity-compatible forms:

• Primitive types like bool, u8…u128, U256, String, and Address map directly to Solidity equivalents (bool, uintN, uint256, string, address).
• Arrays, vectors, slices and tuples (up to 12 elements) are automatically converted in Solidity equivalent sequences
• Option<T> is automatically converted into a Solidity-compatible structure that preserves which variant (Some or None) was used, so the semantic meaning isn’t lost on the Solidity side.
• Custom types and enums can be serialized with derive macros, so long as they only contain supported types, or manual implementations of SolEncode and SolDecode can be provided where necessary.

For the full breakdown of supported default/provided type mappings, error mapping and facilities for defining mappings for custom types, see the docs: Rust ↔ Solidity ABI type mapping in ink!

SCALE vs Solidity ABI encoding

Encoding and decoding are about making sure both sides of a contract call interpret the data the same way. The ABI defines exactly how that data should be serialised and deserialised.

In ink! v6, there are two supported ABIs: the native ink! ABI and the Solidity ABI. You can even compile in All ABI mode, creating contracts that handle both.

Here’s how they compare:

Use Solidity ABI for compatibility with Ethereum tools and contracts, ink! ABI/SCALE codec for efficient, rich internal Rust / Polkadot SDK logic. And with dual mode, you can mix them in the same contract.

Function selectors and constructors

ink! Solidity ABI mode adopts the 4-byte selector (keccak256("fnName(type1,type2)")) used by Solidity for message calls, and only one constructor (with no selector) is allowed.

Primitives

Where to Start

Build your contract with Solidity ABI enabled, ink! will generate the metadata artifacts that wallets, explorers, and Solidity tooling rely on to interact with it. See the Ethereum compatibility tutorial to put them to use!

Experimenting With Dual ABI

You can build an ink! contract that speaks Solidity ABI at the edges (so MetaMask and Solidity contracts work out of the box), while still using SCALE internally for speed, lower costs and richer / Polkadot native data types.

This dual ABI pattern unlocks interesting use cases:

• Data feeds & oracles: push frequent bulk updates without blowing up costs.
• Cross-chain contracts (XCM): use the same types used in XCM. zk / Verifiable computation: handle large proofs.
• Gaming & NFTs: store and manage complex state or metadata.
• Batch ops & DeFi vaults: run multi-step or aggregated updates efficiently.

Dual ABI really shines when you want Solidity compatibility at the edges, but need SCALE’s efficiency and richer Polkadot-native types under the hood.

Looking Ahead

With ink! now fluent in Solidity ABI and PolkaVM running these contracts natively, Polkadot is opening its doors to the world’s largest smart contract developer pool. Solidity projects can deploy into Polkadot’s high-performance, interoperable environment without rewriting their core logic, bringing more projects, assets, and liquidity.

ink!, written in Rust and backed by its performance and safety guarantees, can act as powerful middleware, bridging complex Polkadot features with common Web3 dApp development. In this new landscape, Ethereum-born contracts and Polkadot-native ink! will not only coexist but actively amplify each other’s success!