Multi-chain crypto wallets have a UX problem nobody talks about: you need to keep track of which chain you're on, which address belongs to which network, and which token lives where. Get any of those wrong and your funds end up somewhere they can't be recovered. Today we're launching Unified Wallets — one address that works across every EVM network we support, with automatic routing handled by CPAY.
01 — Why we built this:
The cost of multi-chain fragmentation
EVM-compatible chains share the same address format — a 42-character hex string starting with 0x. A wallet address that works on Ethereum will also receive funds on BNB Chain, Polygon, Base, and Arbitrum at the protocol level. But until recently, almost every wallet product and payment processor treated each chain as a separate wallet — with separate addresses, separate balances, and separate UIs.
That wasn't a UX choice. It was an infrastructure constraint. Different chains had different RPC endpoints, different gas tokens, different confirmation depths, and (until 2022 or so) wildly different security assumptions. Treating each as a separate wallet kept the engineering simpler. The cost of that simpler engineering was paid by users:
- Wrong-chain mistakes remain the single biggest cause of irrecoverable losses in crypto payments. Funds sent to the right address on the wrong chain are gone unless the operator can manually recover them — which usually means they can't.
- Reconciliation gets harder the more chains you support. Your accountants have to track balances across N wallet IDs, your support team has to disambiguate which network a customer used, and your dashboards become forests of duplicates.
- Customer onboarding gets worse. Telling someone "send to this address" is one instruction. Telling them "send USDT on Polygon to this address but USDT on Ethereum to that address" is a friction trap.
Unified Wallets flip the pattern. Instead of one address per network, you have one address that works on every network — and CPAY handles the routing transparently.
02 — What it does:
One wallet, all EVM chains
A Unified Wallet is a single CPAY wallet record that:
- Has one address. A standard 42-character EVM address. It looks identical to a regular Ethereum address because under the hood, it is a regular EVM address.
- Receives on any supported network. Deposits to that address are detected automatically — whether they're sent on Ethereum, BNB Chain, Polygon, Base, Arbitrum, Optimism, or any other EVM chain CPAY supports.
- Maintains separate per-network balances. You see USDT on Polygon and USDT on BNB Chain as two distinct balance entries in your dashboard — same address, different chains, separate ledgers.
- Routes outgoing payments to the correct network. When you withdraw, you choose the network at send time. CPAY signs and broadcasts on the right chain.
The address is yours, deterministically derived from your CPAY account credentials. It's the same address you'd see on any block explorer if you queried it directly — Etherscan, BscScan, Polygonscan, all return the same record because the address space is shared.
03 — How it works:
Under the hood
The cryptography here is not new — it's been built into the EVM standard since day one. What's been missing is good infrastructure to use the property. Most wallet UIs ask "which chain?" because they only listen to one network at a time. Most payment processors generate a new address per chain because they keep them in separate scoping namespaces. Bridging products charge fees to "move" tokens that, in reality, never need to move at all.
CPAY's Unified Wallets bridge that infrastructure gap with four moving parts:
- One key, multiple chain listeners. A single non-custodial key controls funds on every supported chain. CPAY runs an indexer that watches deposits to that address across all networks simultaneously.
- Deterministic per-account derivation. The address you see in your account is deterministically derived from your account credentials using
BIP-32 / BIP-44at the account level, then exposed as a single shared address across networks. - Per-chain balance bookkeeping. Your dashboard shows balances per network because that's what's economically meaningful — USDT on Polygon has different liquidity, gas, and bridges than USDT on Base. The address is unified; the funds are per-chain.
- Routing at send time. When you withdraw, CPAY signs the transaction on the correct network. If you're moving USDT from Polygon to a Polygon recipient, no bridging is involved — it's a direct Polygon transaction.
The infrastructure shift is real, but the UX shift is the point: one address, no juggling, automatic routing. From the outside it looks like a simpler wallet. Under the hood it's a multi-chain indexer with a shared address space.
04 — Before / after:
What actually changes
Concretely, here's what changes for a business operating across multiple chains.
For your dashboard, the count of wallets drops from 5+ to 1. Address book entries: 5+ to 1. The "wrong network" question disappears from customer support tickets. Reconciliation gets meaningfully simpler — same address, lookups by chain.
For your customers, the confusion is gone. The wrong-chain risk is gone. The confidence in your platform goes up, because the thing that always felt fragile (multi-chain addresses) no longer is.
05 — Bonus shipped:
Dynamic miner fee
While we were rewriting the wallet logic, we also rewrote how we calculate gas. Previously, CPAY used a conservative fixed gas premium to make sure transactions confirmed quickly. The trade-off: you paid more than you needed during low-traffic hours.
Now, every transaction reads real-time network fee data and adjusts. When the network is quiet (3am UTC on Ethereum, most of the time on Base), you pay less and confirm fast. When it's congested (a major DeFi launch, an NFT mint, weekend bull run), you pay what's actually needed to confirm in a reasonable time — not 3× that "to be safe."
Faster confirmations when the network is quiet. No overpaying when it isn't. Nothing for you to configure — it just works.
06 — Honest trade-offs:
When NOT to use Unified Wallets
There are real cases where you want chain-segregated wallets. The trade-offs are worth being upfront about:
- Strict per-business-unit accounting. If your accounting policy requires each business unit's funds to be in physically separate wallets — not just labeled as separate — unified addresses make that harder. Use per-business-unit addresses instead.
- Counterparty-specific addresses. Some compliance setups assign one address per major counterparty for transaction monitoring. A unified address can support this, but it requires extra bookkeeping on your side.
- Per-checkout address rotation. If you generate a fresh address for each checkout to prevent address reuse (privacy, sometimes security), you're already not in unified-wallet territory.
For 90%+ of payment and treasury use cases, Unified Wallets are the right default. For the edge cases above, CPAY still supports classic per-chain wallets — you just opt out of unified mode in the dashboard toggle.
07 — Getting started:
Two clicks to enable
Already a CPAY customer? Switching is two clicks:
- Open your CPAY dashboard → Wallets
- Toggle the segmented control at the top to Unified Wallets
That's it. You now have a new unified EVM address. Old per-chain addresses still work — incoming deposits on them are routed to the same balance. Nothing breaks during the transition.
Not on CPAY yet? Sign up — the unified wallet is generated immediately on your first login, no setup fee, no credit card. Drop a test deposit on any supported network and watch the balance appear in the dashboard within seconds.
