How Keeper Wallet Uses the Blockscout Pro API to Power a Multichain Wallet
Keeper (formerly Tonkeeper) uses the Blockscout Pro API for blockchain data and links out to the Blockscout explorer for transactions, across Ethereum, Arbitrum, Base, and BNB Chain.
Tonkeeper spent years as the leading self-custody wallet on TON. Earlier this year the project rebranded to Keeper and added Ethereum, Bitcoin, Arbitrum, Base, and BNB Chain, all with a single seed phrase, cross-chain swaps and a multichain dApp browser built in. With this shift, Keeper needs EVM chain data at the same scale it already handles TON data.
We caught up with the Keeper team to talk about their new updates and how Blockscout fits into their stack.

Hi guys, great to connect! First off, tell us more about Keeper and your multichain expansion. What do you guys do and what differentiates you from other wallets on the market?
Keeper is an open-source, self-custodial wallet. It started as Tonkeeper, the main independent wallet on TON. In September we became Keeper and added Bitcoin, Ethereum, Base, Arbitrum, BNB Chain and TRON, all from one seed phrase in one app.
Four things set us apart:
- Self-custody by default. Your keys never leave your device. There's no Keeper account and no server holding your funds.
- No KYC. You install the app, create a wallet and start using it. We don't ask for an email or ID, and we don't run third-party tracking.
- Open source. Our wallet code is public on GitHub. Anyone can read exactly what the app does with their keys and their data.
- A simple interface. All chains sit in one clean portfolio view, with no network switching to manage. Battery pays network fees, so you can send USDC on TRON without holding TRX.
Most self-custody wallets make you pick: strong values or a good interface. Keeper is built so you don't have to choose.
That's great you guys are open source! From a data persective, where does Blockscout fit in?
Blockscout does two jobs for us on EVM chains.
First, the Blockscout Pro API is our main source for account activity on Ethereum, Base and Arbitrum. It feeds the transaction history users see in the app.
Second, Blockscout explorers are where users go to check things onchain. Every EVM transaction and address in Keeper opens on the matching Blockscout explorer.
We picked Blockscout for this because the code is open and transparent, like Keeper. Users can check their activity on an explorer whose code is as open as the wallet's.

What data are you pulling through the API, and which chains does it run across?
The API gives us each address's full activity history:
- native ETH transfers
- ERC-20 token transfers
- contract interactions, including swaps and dApp transactions
- transaction status, fees and timestamps
It runs on Ethereum, Base and Arbitrum.
Keeper uses a split setup: every chain has a main provider and a fallback for each job (balances, activity, fee estimation, broadcasting).
Walk us through what a user actually sees. Someone sends a transaction on Ethereum with their Keeper wallet, what's pulled from the API directly in-app, and what sends them out to the Blockscout explorer to check their transactions?
Say a user sends ETH from Keeper:
- Right after sending, the transaction shows up in their activity feed as pending.
- Once it's confirmed, the Blockscout API supplies the final record: amount, token, counterparty, network fee and status. We add fiat value and token details on top.
- Tapping the transaction opens its detail screen, which has a "View in explorer" button. That opens the transaction page on eth.blockscout.com.
- The same goes for addresses. From any wallet or counterparty, one tap opens its address page on the matching Blockscout explorer.
Everyday use stays inside Keeper, and full checks happen on Blockscout. The app and the explorer read from the same data, so the two are always aligned with the same numbers.
What does the Blockscout Pro API offer relative to other EVM data providers? Why did you choose to integrate Blockscout?
- The API and the explorer match. They come from the same indexer, so what's in the app matches the explorer exactly. That's what makes "don't trust, verify" work in practice.
- One API on every chain. The endpoints and response format are the same on Ethereum, Base and Arbitrum. We built one client, and each new chain is a config entry.
- Open source. Blockscout is fully open, so we're not building on a black box. That matches how we build Keeper.
- Wide EVM coverage. Blockscout runs explorers across a large share of EVM chains and L2s, which makes it cheap for us to add new networks.
Before launch, we linked out to a separate explorer for each chain. Moving to Blockscout gave users one familiar interface everywhere.

From a development standpoint, how much work was it to wire up the API and explorer links across multiple EVM chains at the same time? What have been some challenges you’ve run across during the integration?
The core integration was quick because the API is the same on every chain: one client, with the chain passed as a parameter. Explorer links for transactions and addresses are templates in our remote config, so we can add a chain or change a link without shipping an app update.
Two things took real work:
- Response times. Response times were slow under load early in integration. We shared request measurements and logs with the Blockscout team, and they worked with us directly to bring response times down before launch.
- Enrichment. Activity data comes without prices or full token metadata, so we added our own pricing and token-metadata layer on top. Users see fiat values and verified-token labels throughout the app.
You already run on TONAPI for TON data, and you’re now serving the Bitcoin ecosystem as well as EVM-based chains. How does the Blockscout Pro API sit alongside that - has keeping different chains in sync caused any friction?
TonAPI is our own infrastructure, built by the Tonkeeper team, and it still serves all TON data. For every other chain we built a provider-agnostic layer. Each chain maps each job to a main provider and a fallback, and the app only sees one standard data model.
That layer is why keeping chains in sync never became a user-facing problem. Most of the engineering went into standardizing the data, so that a Bitcoin transfer, a swap on Base and a TON jetton transfer look and behave the same in the activity feed. The fallback setup means a slow provider slows down one job on one chain, not the whole wallet.
What's next for you guys on the roadmap? Are you thinking about integrating more EVM chains or bringing in new features?
- More chains. We'll add EVM networks where users ask for them, and Blockscout's coverage makes each one fast to ship.
- Battery everywhere. Gasless transactions will reach more chains and more types of action.
- Trading and prediction markets, coming soon inside the wallet.
The goal stays the same: a wallet where crypto gets used, not just stored, with no compromise on self-custody.

Thanks guys for your time! How can people get started with Keeper?
Download Keeper, create a wallet or import an existing seed phrase, and you're live on every supported chain. You don't need an account or KYC.
- Website: https://keeperwallet.com/
- Download: https://keeperwallet.com/download
- X: https://x.com/keeper_wallet
- TG: https://t.me/keeper_en
- GitHub: github.com/tonkeeper
Building with the Blockscout Pro API? Get a key at dev.blockscout.com and tell us what you're making.