Deep Dive: Unified Accounts Architecture

One of the friction points in the Polkadot/Substrate ecosystem has historically been the account mismatch between Substrate (AccountId32) and EVM (H160).

For a Dual VM chain like Selendra, this could present a UX challenge. Fortunately, the broader Substrate ecosystem has developed robust solutions for this, which we have gratefully adopted.

We implemented Unified Accounts, a pattern pioneered by teams like Moonbeam and standardized within the Frontier project.

The Architecture

Unified Accounts is a protocol-level mapping that allows users to interact with both the Substrate and EVM layers using a single identity.

The Mapping Standard

The challenge is that you cannot losslessly convert a 32-byte key to a 20-byte key. The solution, developed by the open-source community, involves a bidirectional mapping approach.

We utilize the pallet-unified-accounts (based on open standards) to handle this.

How It Works

1. The Dispatcher: When a transaction enters the pool, the runtime checks the signature scheme.

   • secp256k1 (Ethereum) -> derives H160.
   • sr25519 (Substrate) -> uses AccountId32.

2. The Mapping Layer:
   A trusted precompile maintains the link between the H160 address and the Substrate AccountId32. This ensures that the two representations point to the same underlying storage.

3. The Unified Balance:
   By aliasing the storage, we ensure that a user's balance is consistent whether queried via an RPC call or an EVM opcode. This is a standard feature of the Frontier EVM pallet that we leverage.

Developer Implications

By adopting this standard architecture, we provide:

1. Single Private Key: Users can use their existing Ethereum wallets (like MetaMask) to interact with the chain.
2. Cross-VM Compatibility: Solidity contracts can interact with the native chain logic using standard precompiles.
3. Standard Tooling: Developers can use Hardhat, Foundry, and other standard Ethereum tools without needing custom adapters.

Implementation

Implementing this required careful configuration of the address derivation paths. We followed the EthAccount extension standards to ensure compatibility with existing wallets.

We also utilized the standard CheckWeight signed extensions to ensure gas metering aligns with Substrate's weight model.

Conclusion

Unified Accounts is not a Selendra invention; it is a testament to the interoperability of the Substrate framework. By adopting these open standards, we ensure that Selendra remains compatible with the wider ecosystem.

You can inspect our implementation in our GitHub repository, which is a fork of the upstream Substrate node.