Reading Tangem wallet balances and history into your own stack

Tangem keeps nothing about your coins on its own servers. The company says so plainly in its privacy materials, and that single design choice decides how a third party integrates the wallet. There is no central balance to query. Balances live on-chain, derived from keys the card's secure element never lets out, so integration here means reading the blockchain on the user's behalf — from the wallet's own public keys — and folding dozens of networks into one shape your systems can poll. That is the work this page scopes.

The dependable path is a read-only sync keyed on the wallet's extended public key. A user exports an xpub from the app, we derive its addresses, and we poll a chain indexer for balances and transactions past a stored cursor. Where the app adds value of its own — fiat valuation, Tangem Express swap quotes, TON staking and Yield Mode positions — we mirror those surfaces by analyzing the app's own traffic. Native xpub export is the clean handoff; traffic analysis fills the gaps.

Data you can pull from a Tangem wallet

Three routes to the data

Each route reaches a different slice, and they stack.

1 · On-chain read via the wallet's public keys

This is the backbone. Given an xpub or address list the user consents to share, we derive addresses under BIP44 — the same path Tangem, MetaMask and Trust Wallet all use for a given chain — and read balances and the full transaction history for every network the wallet touches. It is durable because it rides public blockchains rather than a private endpoint that can change under you. We set up address discovery, the indexer access and the cursor store as part of onboarding, with you.

2 · Interface and protocol analysis of the app's backend traffic

The portfolio view is more than raw chain data: it carries fiat marks, Express swap quotes and routing, and staking and Yield Mode positions that the app assembles. We capture and document those calls against a consenting account, so the aggregated surfaces the app shows are reproducible in code. Durability tracks app releases here, so we version the capture and re-check it when the app moves.

3 · Native export from the app

Tangem lets a user export an extended public key directly. That hands the on-chain route everything it needs with no capture at all — the lowest-effort, most stable entry point. We document the exact in-app steps so a non-technical user can produce the key.

In practice we build on route 1 as the backbone, seed it from a native export under route 3, and add route 2 only for the swap, staking and fiat surfaces a given customer actually needs. Most portfolio and accounting use-cases never need more than the first and third.

Reading a wallet in code

One account, one chain, cursor-based delta sync. Auth is nothing more than a read-only public key; spending authority never enters the picture.

// Delta sync for one Tangem account on one chain.
// Input: xpub exported from the app (Wallet → generate extended public key)
GET /v1/{chain}/xpub/{xpub}/txs?after_block={cursor}&limit=100

200 OK
{
  "chain": "ethereum",
  "derivation": "m/44'/60'/0'/0",
  "balance":  { "native": "1.2843", "unit": "ETH" },
  "tokens": [
    { "contract": "0xdAC17...", "symbol": "USDT", "balance": "540.00", "decimals": 6 }
  ],
  "txs": [
    { "hash": "0x9f2c...", "block": 21345677, "ts": "2026-06-14T08:41:02Z",
      "direction": "in", "value": "0.5", "asset": "ETH" }
  ],
  "next_cursor": 21345680
}

// Persist next_cursor per (wallet, account, chain) and re-poll from it.
// Re-read the last few blocks each cycle so a reorg corrects a balance.
// During first load, run address discovery with a gap limit, then go incremental.

One schema across chains

Forty UTXO addresses, an account-model EVM chain and a TON staking position should not each land in their own bespoke table. We normalize them into a single record so downstream code reads one shape.

{
  "wallet_ref": "local-handle-001",        // your handle, not a Tangem identifier
  "account": "Main",                        // a wallet can hold up to 20 accounts
  "positions": [
    { "chain": "bitcoin", "asset": "BTC", "balance": "0.04120", "fiat": { "usd": "..." } },
    { "chain": "ton",     "asset": "TON", "staked": "120.0", "provider": "yield_mode" }
  ],
  "as_of_block": { "bitcoin": 840122, "ton": 41233901 },
  "cursor": { "bitcoin": 840122, "ton": 41233901 }
}

What we hand over

The headline deliverable is code that runs, not a folder of paperwork.

• Runnable source first: Python and Node clients (Go on request) that take an exported xpub, run address discovery, and emit normalized balance and transaction records.
• A poller with a persistent per-chain cursor store, plus webhook-handler scaffolding for the indexers that push updates instead of waiting to be asked.
• A backfill path kept separate from incremental sync, so a new wallet loads its full history once and then carries only deltas.
• An automated test harness with recorded per-chain response fixtures, so behaviour is pinned across builds.
• Then, secondary: an OpenAPI description of the normalized read endpoints, a short auth-and-derivation note (how xpub export, BIP44 paths and read-only access fit together), interface documentation, and a data-retention and consent memo for your compliance file.

Consent and the privacy footing

Tangem AG, the Swiss company behind the wallet, is the data controller for the limited personal data it does hold — a newsletter email, app analytics, crash reports. Wallet addresses, balances and transactions sit outside that set; Tangem states it neither collects them nor links them to identities. That matters twice for our work. The data we sync is the user's own on-chain record, reached only after they hand over a read-only public key, so consent is explicit and narrow by construction. And Swiss FADP plus GDPR (for EU and EEA users) govern any personal data that rides along, so we keep public keys and derived addresses out of logs that could re-identify a person, retain only what the integration needs, and work under NDA where a customer requires it. MiCA, often raised around crypto, is aimed at exchanges and token issuers rather than self-custody tools, so it does not gate reading a user's own wallet. Consent here is revocable in the simplest way there is: stop polling and drop the key.

What we plan around

A few realities of this wallet shape the build, and we handle each rather than passing them back to you.

Accounts and the gap limit

A single Tangem wallet can hold up to 20 independent accounts, and sparse usage leaves gaps between active addresses. We run discovery with a configurable gap limit and reconcile every account under one wallet, so nothing is silently truncated.

Chain reorganizations

On each poll we re-read the last few blocks per chain before advancing the cursor, so a short reorg corrects a balance instead of stranding a stale figure at the tip.

The non-custodial boundary

Only public material — an xpub or address list — crosses into the integration. Signing keys are generated on the card and never leave it, and we design the read path so it never needs spending authority. Access to a consenting account or the user's exported key is arranged with you during onboarding.

Per-chain normalization

Decimals, dust thresholds and the UTXO-versus-account distinction differ across the 80-odd networks. We map each into the one schema above and attach fiat marks from a price source you pick.

Screens we mapped

The data surfaces above were checked against the app's published store screenshots. Tap to enlarge.

Sources behind this page

Checked in June 2026 against Tangem's own documentation. The on-chain read path follows Tangem's published guide to exporting an extended public key and its notes on BIP44 derivation; the swap and staking surfaces come from Tangem's Express write-up; the privacy footing comes from Tangem's statement on what it does and does not collect.

• Tangem — how to get the xpub (extended public key)
• Tangem — derivation paths in the wallet (BIP44)
• Tangem — Express swap and exchange aggregation
• Tangem — what the app does and does not collect

OpenFinance Lab — interface mapping, reviewed 2026-06-15.

Other wallets in the same bucket

If a unified integration spans several wallets, these sit naturally beside Tangem — same kind of on-chain data, similar derivation, no ranking implied.

• Ledger Live — companion app for Ledger devices; holds the same multi-chain balances and transaction history, read from on-chain addresses.
• Trezor Suite — interface for Trezor hardware wallets; surfaces balances and history per derivation path, another xpub-shaped read.
• OneKey — open-source hardware-and-app wallet; tracks balances across many networks that fold into a shared schema.
• SafePal — app-plus-card wallet with a built-in swap and markets layer that resembles Tangem Express.
• Keystone — air-gapped QR-signing wallet; the app side reads on-chain state for the device's addresses.
• Cypherock — seed-less hardware wallet that splits keys across cards; the app exposes per-account balances that normalize the same way.
• D'CENT — biometric hardware wallet with a mobile app spanning Bitcoin, Ethereum and more, all from on-chain reads.
• MetaMask — software wallet for EVM chains and beyond; the same BIP44 derivation aligns its addresses with the Tangem read path.
• Trust Wallet — multi-chain mobile wallet holding balances, token lists and swap activity a single integration can reconcile.

Questions we get about Tangem

If Tangem stores nothing itself, how fresh is the synced data?

Freshness is set by your poll cadence and each chain's finality, not by Tangem. We read balances and transactions straight from the blockchain using the wallet's public keys, advancing a per-chain cursor each cycle. Where an indexer can push updates we wire a webhook so changes arrive in near real time; otherwise the poller runs on whatever interval you pick.

Do you ever need our private keys or the physical card?

No. The integration only uses public material, an extended public key or a list of addresses. Signing keys are generated on the card's secure element and never leave it, and a read-only sync has no reason to ask for them.

Can one integration cover all the networks a Tangem wallet touches?

Yes, normalized into a single schema, though each chain needs its own indexer behind the scenes. We scope the build to the networks you actually use rather than wiring all eighty-plus up front, then add others as needed. UTXO chains and account-model chains map into the same record shape.

What does a working Tangem sync include, and how long does it take?

A first delivery is usually one to two weeks: runnable Python and Node clients that turn an xpub into normalized balance and transaction records, the poller and cursor store, recorded test fixtures, and the interface docs. You give us the wallet and the networks that matter; access and consent are arranged with you.

Getting started

Hand us the wallet name and the networks you care about, and a working Tangem sync lands in one to two weeks. Source-code delivery starts at $300 and is billed only after the code is in your hands and running; if you would rather not host anything, call our endpoints and pay per call with nothing up front. Start the conversation at /contact.html.