Tonkeeper is no longer just a TON wallet.
The product has been rebranded as Keeper and now supports seven networks:
TON
TRON
Ethereum
Bitcoin
Arbitrum
Base
BNB Chain
At first glance, this looks like a normal wallet expansion.
Technically, however, moving from a single-chain wallet to a multichain product introduces a much harder problem:
How do you make several incompatible blockchain systems feel like one wallet without hiding the differences that users still need to understand?
Keeper’s rebrand is interesting because it shows both the benefits and the complexity of that transition.
From a TON Wallet to a Multichain Interface
Tonkeeper originally focused on TON.
That gave the wallet a relatively narrow technical environment to support:
TON addresses
TON transaction formats
TON fee mechanics
TON-specific dApps
TON wallet derivation rules
Keeper now has to abstract several very different blockchain architectures behind one interface.
Bitcoin uses a UTXO model.
Ethereum, Base, Arbitrum, and BNB Chain use EVM-style accounts.
TON has its own account and wallet-contract architecture.
TRON has another execution and fee model.
The user may see one app.
Underneath, the wallet is dealing with several completely different systems.
Multichain Does Not Mean Interchangeable
One of the biggest UX risks in multichain wallets is making everything look too similar.
A user may see USDT on:
TON
TRON
Ethereum
BNB Chain
and assume those balances are interchangeable.
They are not.
Each version exists on a specific network and follows that network’s rules.
A multichain wallet therefore needs to abstract complexity without removing important information.
At minimum, users still need to understand:
Which network the asset belongs to
Which address format is being used
Which gas asset is required
Whether a bridge is involved
Whether the receiving platform supports that network
The wallet UI can simplify these steps, but it cannot remove the underlying blockchain boundaries.
The Most Important Migration Detail: Derivation Paths
For existing Tonkeeper users, the biggest technical issue is not branding.
It is wallet derivation.
Keeper’s documentation explains that the older TON-only wallet and the new multichain wallet can use different derivation paths.
A recovery phrase is not simply a password that always reconstructs one universal address.
Wallet software combines the recovery phrase with a derivation scheme to generate private keys and addresses.
Conceptually:
Seed phrase → derivation path → private key → blockchain address
Change the derivation path and the resulting address can change too.
That means a recovery phrase imported into the wrong wallet structure may produce an address the user has never seen before.
The original funds have not necessarily disappeared.
The wallet may simply be deriving a different key.
Why This Can Look Like Lost Funds
Imagine an existing Tonkeeper user has a TON wallet containing assets.
They install Keeper.
They enter the same recovery phrase into a new multichain wallet flow.
The app displays a different TON address.
The immediate assumption may be:
“My wallet is empty.”
But the blockchain has not moved anything.
The assets may still exist at the original address.
The new wallet simply reconstructed a different account from the same underlying seed.
This is why wallet migration should be treated as a key-management operation rather than a normal app upgrade.
A Safer Migration Workflow
For existing users, a safer process is:
Keep the original wallet accessible.
Add the existing TON wallet using the correct wallet type.
Verify the recovered address.
Check the address against a block explorer.
Create a separate multichain wallet if needed.
Transfer a small test amount first.
Verify receipt.
Only then move larger balances.
Do not delete the original wallet until the new setup has been fully verified.
This is especially important because wallet mistakes are often irreversible.
Self-Custody Changes the Support Model
Keeper remains a self-custodial wallet.
That means the user controls the recovery phrase and private keys.
From a security perspective, this removes one major dependency:
Keeper does not need to hold customer funds like a centralized exchange.
But the tradeoff is important.
There is no traditional password-reset mechanism for a lost recovery phrase.
If the user loses:
The device
and
The recovery phrase
the wallet provider cannot recreate the private keys.
Self-custody shifts responsibility from the service provider to the user.
Recovery Phrase Security Still Matters More Than Branding
The rebrand does not change the basic security model.
Recovery phrases should not be stored in:
Screenshots
Cloud drives
Messaging apps
Email
Unencrypted note applications
Anyone who gets the phrase can potentially reconstruct the wallet.
Users should also be careful with fake migration pages.
A major rebrand creates an obvious phishing opportunity.
Attackers can create websites claiming:
“Upgrade your Tonkeeper wallet.”
“Convert Tonkeeper to Keeper.”
“Verify your seed phrase.”
A legitimate migration should never require users to send their recovery phrase to a website or support agent.
Keeper Battery Is a Form of Gas Abstraction
One of Keeper’s more interesting UX features is Battery.
Battery allows users to fund a balance using crypto or a card and use that balance to cover transaction fees on TON and TRON.
This solves a familiar wallet problem.
A user may hold USDT but have no native gas asset.
Without abstraction, they might need to acquire TON or TRX before moving the stablecoin.
Battery hides some of that friction.
From a developer perspective, this is a form of gas abstraction.
The user interacts with a higher-level payment mechanism while Keeper handles the underlying fee requirement.
But Battery Is Not Universal Gas Abstraction
The feature currently applies to TON and TRON.
That does not mean Keeper eliminates gas requirements across every supported network.
Ethereum still has ETH gas.
Base and Arbitrum follow their own EVM fee structures.
BNB Chain requires its native gas mechanism.
Bitcoin uses transaction fees based on its own UTXO and fee-market model.
This is another example of why multichain UX has limits.
A wallet can unify the interface.
It cannot make seven different networks follow one fee model.
MoonPay Adds Another Infrastructure Layer
Keeper also integrates MoonPay Trade for in-wallet purchases and swaps.
This makes the product feel more complete because users do not necessarily need to move between multiple applications.
But technically, it introduces another service layer.
The architecture becomes something like:
User
→ Keeper interface
→ third-party trading or fiat provider
→ blockchain network
The wallet remains self-custodial, but some services are delivered by external infrastructure.
That means users may still encounter:
Regional restrictions
Provider fees
Exchange-rate spreads
Slippage
Routing differences
Failed transactions
Self-custody does not mean every service inside the wallet is decentralized.
Cross-Chain UX Is Mostly an Abstraction Problem
A multichain wallet has to answer a difficult product question:
How much complexity should the interface hide?
Too much technical detail makes the wallet difficult for beginners.
Too little detail creates dangerous assumptions.
For example, a “Swap” button may look simple.
But underneath, the operation could involve:
A DEX trade
A bridge
A liquidity aggregator
A wrapped asset
Multiple network fees
If the user does not understand that a cross-chain route is being used, debugging a failed transaction becomes much harder.
Good multichain UX therefore requires progressive disclosure.
Simple by default.
Detailed when necessary.
Address Formats Create Another Failure Mode
Different chains use different address systems.
Bitcoin addresses do not look like Ethereum addresses.
TON addresses follow different encoding rules.
TRON has its own conventions.
EVM chains such as Ethereum, Base, Arbitrum, and BNB Chain may use visually similar 0x addresses.
That last category is especially dangerous.
The same-looking address can exist across multiple EVM networks, but the assets still live on separate chains.
Sending an asset to a platform that does not support the selected network can create a recovery problem even when the address itself appears valid.
Wallets therefore need to validate both:
Destination address
and
Destination network
The Wallet Market Is Moving Toward Chain Abstraction
Keeper’s expansion reflects a broader wallet trend.
Users increasingly expect one interface for:
Multiple networks
Swaps
Staking
dApps
Fiat access
Bridges
Token management
The long-term direction is often described as chain abstraction.
The user should care less about which chain performs the transaction.
But the industry is not fully there yet.
Network selection, gas, bridges, liquidity, and address formats still matter.
Wallets can hide some of these details.
They cannot safely pretend they do not exist.
What Developers Can Learn From Keeper
Keeper’s evolution highlights several useful design principles for wallet developers.
Preserve Backward Compatibility
Existing users should not lose access because the product architecture changes.
Make Wallet Type Explicit
A TON-only wallet and a multichain wallet should not look identical if they use different derivation logic.
Verify Before Migrating
Address confirmation should be part of the migration UX.
Separate Network Identity From Asset Identity
USDT on TRON and USDT on Ethereum should never be presented as interchangeable balances without clear routing logic.
Expose Third-Party Boundaries
Users should know when they are interacting with MoonPay or another provider instead of the wallet itself.
Abstract Gas Carefully
Gas abstraction improves UX, but developers should clearly indicate which networks support it.
Final Thought
Tonkeeper becoming Keeper is more than a branding change.
It represents the transition from a specialized TON wallet to a multichain self-custody platform.
That creates a broader product.
It also creates more architectural responsibility.
The most important lesson for existing Tonkeeper users is that the new multichain wallet should not automatically be treated as the same wallet structure as the old TON-only setup.
The most important lesson for developers is broader:
Multichain UX works only when abstraction simplifies the experience without hiding the technical differences that affect key derivation, fees, addresses, and transaction safety.
That balance will determine whether the next generation of wallets genuinely feels chain-agnostic—or simply places more complexity behind one interface.
Top comments (0)