A Polkadot wallet is not an Ethereum wallet with a different RPC URL. It has to understand SS58 addresses, sr25519 keys, runtime metadata that changes with every upgrade, existential deposits, staking and nomination pools, and cross-chain transfers over XCM. This guide walks through each piece so you can scope a build or judge a vendor's proposal.
How Polkadot accounts differ from EVM accounts
Polkadot accounts are 32-byte public keys rendered in the SS58 address format. The same key produces different-looking addresses depending on the network prefix (prefix 0 for Polkadot, 2 for Kusama, 42 for the generic Substrate format). A wallet must display the right encoding for the chain the user is on, and it must warn users that the string they paste is the same account on another network, not a different one.
Keys usually use sr25519 (Schnorr signatures over Ristretto), with ed25519 and ECDSA also supported. Seed phrases are BIP-39 mnemonics, but derivation is not BIP-44: Substrate uses its own derivation-path syntax with hard (//) and soft (/) junctions. If you import a phrase created in another wallet and derive differently, the user sees an empty account and assumes funds are gone. Supporting the derivation schemes of the major wallets (Polkadot.js, Talisman, SubWallet, Nova, and Ledger's scheme) is a real compatibility task, not a nice-to-have.
Two more rules trip up newcomers. The existential deposit means an account whose balance falls below a threshold is reaped, so "send max" must account for it. And DOT has 10 decimal places (the smallest unit is a planck), not 18.
The Polkadot Hub shift
Polkadot has been moving user-facing functionality off the relay chain and onto Asset Hub, now presented as Polkadot Hub: balances, asset issuance, staking-related operations and, increasingly, Ethereum-compatible smart contracts. For a wallet this changes where you read balances and submit transactions. Older wallet code that assumes "DOT lives on the relay chain" needs to be revisited. Check the current state in the official Polkadot documentation before you design the account model, because the migration has moved quickly.
Core components of a Polkadot wallet
| Component | What it does | Polkadot-specific detail |
|---|---|---|
| Key manager | Generates, encrypts and stores keys | sr25519 by default; Substrate derivation paths; optional Ethereum-style keys for EVM-compatible accounts |
| Chain client | Reads state, subscribes to blocks, submits extrinsics | Use polkadot-api (PAPI) or Dedot; a light client (smoldot) removes reliance on a single RPC node |
| Metadata handling | Decodes calls and storage | Runtime metadata changes on upgrades; the wallet must refresh it and show human-readable calls |
| Transaction builder | Constructs and signs extrinsics | Transaction extensions such as nonce, mortality era, tip and the metadata hash check |
| Staking module | Nominate, bond, unbond, join pools | Nomination pools for small holders; unbonding period of roughly 28 days on Polkadot |
| XCM transfers | Moves assets between chains | Fee estimation on both sides; reserve vs teleport semantics |
| dApp connector | Exposes accounts and signing to websites | The injected-extension interface used by Polkadot dApps; optionally WalletConnect |
Signing: hot keys, Ledger and Polkadot Vault
Hardware support on Polkadot used to require a separate Ledger app per chain. The generic Polkadot Ledger app relies on the metadata hash check (introduced via RFC-0078): the transaction commits to a hash of the runtime metadata, so the device can verify it is decoding the call correctly without hardcoding every pallet. Your transaction builder needs to include that extension for Ledger signing to work.
Polkadot Vault (formerly Parity Signer) turns an offline phone into an air-gapped signer that exchanges QR codes with the online wallet. Supporting it means implementing the QR payload format and metadata update flow. For institutional users, the multisig and proxy pallets matter more: a proxy lets a hot key perform only staking actions, for example, while the cold key stays offline.
Custody model and scope
The decisions that drive scope are the same ones covered in the broader blockchain wallet development guide: custodial versus non-custodial, browser extension versus mobile, and whether you use MPC. Polkadot adds a few of its own:
- Which chains: Polkadot Hub only, or also other parachains such as Moonbeam, Astar, Hydration and Bifrost, each with its own assets and occasionally its own account type.
- EVM accounts: parachains like Moonbeam use 20-byte Ethereum-style addresses, so a wallet covering them handles two account families.
- Governance: OpenGov voting, delegation and conviction locks are expected features for engaged holders.
- Identity: on-chain identity now lives on the People chain, so displaying names means querying a different chain.
Build process and realistic effort
- Define the chains, account types and custody model, and decide whether you are building a full wallet or a white-label fork of an open-source one.
- Build the key manager and derivation compatibility tests against seed phrases from the major wallets.
- Integrate PAPI or Dedot, with a light client option and fallback RPC endpoints.
- Implement transfers, existential-deposit handling, fee estimation and human-readable call decoding.
- Add staking and pools, then XCM transfers between the chains you support.
- Add Ledger and Vault signing, then run an external security review of key storage and the dApp connector.
As an estimate: a focused non-custodial mobile or extension wallet covering Polkadot Hub, staking and a handful of parachains is typically three to five engineers for four to six months. Adding MPC custody, many parachains or institutional multisig flows pushes it well past that. Forking an existing open-source wallet shortens the first release but leaves you maintaining a large codebase you did not design.
What to ask a team before you hire them
- Which client library do they use, and how do they handle runtime upgrades without breaking users?
- Have they implemented the metadata hash extension and tested with a real Ledger device?
- How do they test derivation compatibility with other wallets?
- How do they handle the existential deposit and XCM fee estimation edge cases?
If you are also building the applications that will connect to the wallet, see the companion guides on Polkadot dApp development and the wider Polkadot development landscape. Kusama uses the same stack, covered in Kusama development.
Frequently asked questions
Can I reuse an Ethereum wallet codebase for Polkadot?
Only partly. UI, storage and security architecture carry over, but key derivation, address encoding, transaction construction, metadata decoding and staking are all different. Budget for a new chain layer.
Do I need my own Polkadot node?
Not necessarily. Many wallets use public RPC providers with a light client as a trust-minimized option. Running your own nodes improves reliability and privacy once you have real traffic.
Why does an imported seed phrase show an empty account?
Usually a derivation mismatch or the wrong key type. The same phrase can produce different accounts depending on sr25519 versus ed25519 and on the derivation path used by the original wallet.
Is MPC custody available for Polkadot?
Yes, though support for sr25519 and ed25519 in MPC libraries is less mature than for ECDSA. Check that your MPC provider supports the key type you need before committing.