Hi Polkadot community,
I would like to highlight the need to standardize the use of Ethereum-style H160 addresses and the adoption of EVM standards for dApp development on Polkadot. The ecosystem already includes functioning EVM and PVM runtimes; this effort focuses on aligning dApp development with industry standards, while keeping Substrate as a low-level layer for parachain and system developers.
The goal is to reduce operational costs and complexity for developers by providing a standardized interface compatible with existing Ethereum tooling (wallets, ethers.js, viem), while keeping Substrate accessible as a low-level layer for parachain and system developers.
Key highlights:
1- H160 Address Standard Compliance
Ethereum-style H160 addresses standardized for accounts and “virtual contract” endpoints.
H160 is used strictly for identity and routing, not for executing EVM bytecode.
Ensures seamless integration with wallets and Ethereum tooling (MetaMask, WalletConnect, ethers.js, viem), fully aligning with industry standards.
2- Precompile Gateway for Standardized ABI Dispatch
A runtime precompile dispatches Ethereum-formatted transactions from the adapter to native Substrate pallets.
Responsibilities:
Verify EIP-155 signatures
Map H160 → Substrate AccountId32
Decode calldata and route to the correct pallet
Supports standard ABI calls for transfers, assets, governance, and other operations without requiring developers to understand Substrate internals.
3- Efficiency & Developer Experience
No unnecessary EVM execution → drastically reduces operational costs, gas overhead, and runtime complexity
Frontend devs see a clean Ethereum-compatible interface, while Substrate remains fully available for parachain/system developers
Simplifies dApp development, improves safety, and accelerates time-to-market.
4- Benefits
Plug-and-play developer UX for dApps
Security-first: avoids common EVM risks (reentrancy, gas griefing, storage collisions)
Industry standard compliance: consistent H160 and ABI interface
Clear separation of layers: dApp developers use the adapter gateway; Substrate remains for advanced system development
This development will be carried out exclusively by Parity Technologies and the Fellowship, ensuring consistency, security, and maintainability across the ecosystem.
Appendix 1
Example for Governance:
interface Governance {
function vote(uint256 referendumId, bool support) external;
}
support = true for “yes”, false for “no”
This is exactly what a developer would see from the EVM perspective
Completely hides Substrate / pallet complexity
What happens internally:
1- Gateway receives the transaction from MetaMask / ethers.js
2-Verifies the EVM signature (secp256k1) → obtains H160 sender
3-Maps H160 → Substrate AccountId
4-Decodes ABI data (referendumId, support)
5- Constructs the corresponding Substrate pallet call:
pallet_conviction_voting::Call::vote { referendumId, aye: support }
6- Dispatches the call in the runtime with Signed(origin)
Developer only sees vote(referendumId, support) — completely unaware of Substrate internals.
Appendix 2
Example: Accessing Virtual Contracts via Ethers.js
Developers interact with virtual contracts exactly like standard EVM contracts.
1. Contract address (H160)
const GOVERNANCE_CONTRACT_ADDRESS = "0x0000000000000000000000000000000000000801";
2. Standard ABI (generated from Solidity interface)
const governanceAbi = [
"function vote(uint256 referendumId, bool support) external"
];
3. Create a contract instance
import { ethers } from "ethers";
const provider = new ethers.BrowserProvider(window.ethereum);
const signer = await provider.getSigner();
const governance = new ethers.Contract(
GOVERNANCE_CONTRACT_ADDRESS,
governanceAbi,
signer
);
4. Call the method
// Vote YES on referendum 42
await governance.vote(42, true);
What the developer sees:
“I am calling a standard EVM contract.”
Under the hood:
-
The transaction goes through
eth_sendTransaction/eth_call -
The virtual contract address is recognized by the gateway/precompile
-
Calldata is decoded according to the ABI
-
EVM signature (H160) is verified and mapped to Substrate
AccountId -
The corresponding Substrate pallet call is constructed
-
The call is dispatched in the runtime
Key point:
From the developer’s perspective, virtual contracts are indistinguishable from regular EVM contracts, while the runtime handles all Substrate-specific type conversions.