Getting balances, history and labels out of Trezor Suite

Every balance and transaction Trezor Suite shows on its dashboard is read from public blockchains through an account descriptor — an extended public key, or xpub — rather than from a private ledger only the vendor can see. That one fact decides how you reach the data. The keys stay on the device; the history sits on Bitcoin, Ethereum, Solana and the other chains the wallet tracks, queryable by anyone who holds the descriptor. So the durable way to mirror a Trezor account into your own system is to read those chains the way Suite does, under the account holder's authorization, then layer back the context — labels, fiat values, trade records — that raw chain data does not carry.

The read that survives Suite's frequent releases is the descriptor-driven one, because it depends on public-chain data and an open indexer rather than the app's shifting front end. The encrypted labels file and the per-account export then supply the human and accounting context. We anchor a build on that on-chain read and fold the app-layer captures in where a project actually uses them.

What a Trezor account actually exposes

Each row below is something Suite surfaces today, mapped to where it comes from and what an integrator would do with it.

Authorized ways into the data

Three routes genuinely apply to a self-custody wallet. Each is something we set up with you during onboarding, not a hoop you clear first.

Consented descriptor plus on-chain index

Reachable: balances, complete transaction history, UTXOs, token holdings and staking. Effort is low to moderate — it needs the account descriptor and an index. Durability is high, since it rides public chains rather than the UI. We arrange the consented xpub with you and either stand up a self-hosted Blockbook index — the same open-source backend Suite itself queries — or point at an instance you already trust.

Protocol analysis of the app's own surfaces

This covers what the chain can't give you: the AES-encrypted labels file, the order trail behind the Invity Buy/Sell/Swap flow, and WalletConnect session metadata. Effort is moderate — it means reading the request and response shapes and the metadata encryption. Durability tracks app versions, so we re-check it on releases. The capture runs against a consenting account or device.

Native per-account export

Suite exports each account's history as CSV, PDF or JSON, with JSON carrying the most detail, per Trezor's documentation. Effort is low and no credentials change hands. The export schema can shift between versions, so this fits one-off or monthly reconciliation rather than a live feed.

If the goal is a live portfolio or accounting sync, build the descriptor-and-index read; it is the part that keeps working after a Suite release. The labels, the Invity trades and the WalletConnect history each need their own capture, so we add those only where a project uses them. A scheduled export pull covers the case where someone just wants a file.

What you receive

• An OpenAPI/Swagger spec for a normalized read service — accounts, balances, transactions, UTXOs, token holdings, staking — modeled on the field set the indexer already returns.
• Runnable source in Python or Node.js: an xpub-to-index client with pagination, a CSV/JSON export parser, a decryptor for the labels file run with the user's key, and an Invity order fetcher.
• A protocol and auth-flow report: how Suite authenticates to its backend, how the metadata file is keyed and AES-encrypted, and the WalletConnect pairing handshake.
• Automated tests against a known testnet descriptor and sample export files.
• Interface documentation plus a short data-handling note covering consent records, retention and GDPR-aligned minimization.

The read, in code

A consented descriptor and an index are enough to reconstruct an account. The field names below come from Blockbook's v2 xpub endpoint, confirmed against its API reference during the build.

# Read a consented Trezor account straight from a Blockbook index.
# The xpub/descriptor is shared by the account holder; no device needed to read.
import requests

INDEX = "https://your-blockbook.example"   # self-hosted, or a trusted instance

def fetch_account(xpub, page=1):
    r = requests.get(
        f"{INDEX}/api/v2/xpub/{xpub}",
        params={"details": "txs", "tokens": "used", "page": page, "pageSize": 50},
        timeout=20,
    )
    r.raise_for_status()                      # surface 4xx/5xx, don't swallow
    d = r.json()
    return {
        "balance":      int(d["balance"]),            # confirmed, base units
        "received":     int(d["totalReceived"]),
        "sent":         int(d["totalSent"]),
        "pending":      int(d.get("unconfirmedBalance", "0")),
        "tx_count":     d["txs"],
        "tokens":       d.get("tokens", []),          # ERC-20 / SPL holdings
        "transactions": d.get("transactions", []),
        "page":         d["page"],
        "total_pages":  d["totalPages"],
    }

acct = fetch_account("zpub6r...")             # descriptor supplied under consent
while acct["page"] < acct["total_pages"]:     # walk the full history
    acct = fetch_account("zpub6r...", page=acct["page"] + 1)
    # merge acct["transactions"] into your normalized store
      

One shape across every chain

UTXO coins and account coins disagree about what a balance is, so the deliverable flattens both into a single record. Downstream code then never branches per coin.

{
  "account_id": "btc-acct-0",
  "chain": "bitcoin",
  "model": "utxo",                 // "utxo" or "account"
  "label": "Cold savings",         // recovered from the encrypted labels file
  "balance": { "base_units": "184250000", "asset": "BTC",
               "fiat": { "eur": 11240.55 } },
  "transactions": [
    { "txid": "...", "ts": 1717000000, "direction": "in",
      "amount": "50000000", "fee": "0" }
  ],
  "tokens": []
}
      

Consent and the rules in play

Self-custody changes the legal picture. There is no bank-style account-information scheme to plug into here — the data is not held by a regulated institution on the user's behalf; it sits on public chains plus a metadata file the user controls. The dependable basis for every read is therefore the account holder's own authorization. They share the descriptor, the export, or the labels key; they can revoke it by moving funds to a fresh account or simply ending the index queries.

The in-app Buy, Sell and Swap flow is different. It runs through Invity, the SatoshiLabs sister company, which reports obtaining a MiCA licence from the Czech National Bank in early 2026 — so order data touched on that side sits inside the EU's Markets in Crypto-Assets regime. Personal data is handled under GDPR, since the vendor is based in Prague. We keep consent records, minimize what we pull, log access, and sign an NDA where the work touches anything sensitive.

What we handle on the build

An xpub is far more revealing than a single address — it lets anyone derive the whole address tree and read the complete history. We treat that as a privacy decision: you choose which accounts to share, we honor the derivation gap limit so discovery stops at the right place, and the index can run inside your own perimeter so the descriptor never leaves it.

Bitcoin and the account-based chains don't agree on what a balance even is. UTXO coins track unspent outputs; Ethereum and Solana track an account balance with token sub-balances. We map both into one record shape during the build, so a UTXO spend, an ERC-20 transfer and a staking reward all land in the same structure.

Suite ships updates often. We anchor the integration on the stable surfaces — the index and the export — rather than the moving UI, and when the export schema or the metadata format version changes, a scheduled check flags it before a downstream sync quietly breaks.

Screens the mapping was checked against

Dashboard, account history, send and receive, and the trading views. Tap to enlarge.

What was checked, and where it came from

The export formats and the metadata/labels structure come from Trezor's own developer documentation; the xpub and UTXO endpoint fields from the Blockbook backend's API reference; the regulatory frame from ESMA's MiCA materials. Reviewed against the current Android listing in June 2026.

• Trezor Suite — transactions export (CSV/PDF/JSON)
• Trezor Suite — metadata and labeling structure
• Blockbook — backend API reference (xpub, utxo)
• ESMA — Markets in Crypto-Assets Regulation (MiCA)

Reviewed on 2026-06-15 by the OpenBanking Studio integration desk.

Other self-custody wallets nearby

The same integration problem recurs across these apps; names are listed for context only.

• Ledger Live — companion app for Ledger devices, holding per-account balances and transaction history across many chains, also read from indexers.
• OneKey — open-source hardware and software wallet with multi-chain accounts and its own backend; comparable account and token data.
• Tangem — card-based seedless wallet whose app tracks balances and transactions for the chains it supports.
• SafePal — hardware and app wallet with portfolio, swap and in-app trading data across multiple networks.
• ELLIPAL — air-gapped wallet whose companion app holds account balances and transfer history.
• ZenGo — keyless MPC wallet carrying account balances, transaction history and in-app buy/sell records.
• Coldcard — Bitcoin-only hardware wallet usually paired with desktop software that reads UTXO data from an indexer.
• NGRAVE — air-gapped wallet with a companion app tracking multi-chain balances and history.
• D'CENT — hardware and app wallet covering several chains, with on-device key generation and portfolio tracking.

A unified integration over several of these means normalizing each wallet's account and transaction view into one schema — the same job the Trezor read does, repeated per source.

Questions we get about Trezor Suite

Do you need my Trezor plugged in every time you read the data?

No. Reading balances and history only needs a consented account descriptor — your xpub. We pull the full picture from a blockchain index the same way Suite does; the hardware device is only required to authorize spends, not to view what an account already holds.

An xpub reveals every address I've ever used — how is that handled?

That is the trade-off with an extended public key, so we scope it. You decide which accounts to share, we honor the derivation gap limit during discovery, and the index can run on infrastructure you control so the descriptor never leaves your side.

Can you bring across the labels and notes I set inside Suite?

Yes. Those live in a metadata file that is AES-encrypted with a key derived on the device, keyed by xpub, transaction id and output index. With your key in the loop we decrypt it and merge account names, address labels and notes into the normalized records.

Bitcoin and Ethereum track balances in completely different ways — do I get one consistent format?

Yes. UTXO chains like Bitcoin and account chains like Ethereum and Solana are normalized into a single record shape, so a token transfer, a staking reward and a UTXO spend all arrive in the same schema.

What about the Buy, Sell and Swap orders made through the app?

Those route through Invity's partner providers rather than Trezor itself. We capture the order records that are reachable and reconcile them against the matching on-chain settlements, so the trade and its blockchain movement line up.

Working with the studio

Source delivery starts at $300: runnable code, the OpenAPI spec, the protocol report, tests and the interface docs, handed over and paid once it is working in your hands. Prefer not to host anything? The same reads are available as a metered API — you call our endpoints and pay per call, with nothing upfront. Builds run in one to two weeks. Tell us which accounts and chains you need reached and we will scope it at /contact.html.