Reading a Trust Wallet user's assets across 100+ chains

Trust Wallet holds no server-side ledger of anyone's money. It derives keys on the device, encrypts them locally with AES, and signs transactions — the balances a user sees are read back from the chains themselves, keyed by the public addresses the wallet derived. That single fact decides how you integrate it. There is no account statement sitting on a Trust server to request; there is a set of addresses, spread across 100+ blockchains as the app's own listing describes it, and the asset state attached to each one.

So the working problem is not "log in and download" — it is: get the user's consent to their own public addresses, resolve every address the wallet would derive, then read balances, transaction history, NFTs and Stablecoin Earn positions off-chain-source for off-chain-source and fold them into one shape. We build that. Below is what is reachable, the route we'd take for this app, and what lands in your hands at the end.

What is actually reachable, and where it comes from

Each row below maps a domain to its real origin for this app, the granularity you can expect, and what it tends to feed downstream.

How we'd reach it

Consented address access, then on-chain reads

The wallet owner shares their public addresses or an extended public key. From an xpub we derive the full address set the wallet would, then read state through RPC nodes and indexers. Everything that is on-chain is reachable this way, it is read-only by construction, and it survives app updates because chains do not change underneath you. We arrange the indexer and node access during onboarding.

Protocol analysis of the aggregation tier

Trust normalizes raw chain data into the portfolio and history views users see — pricing, token discovery, decoded transfers. Studying that tier under your authorization lets the feed match the in-app numbers exactly, including fiat valuation. It needs a re-validation pass when the app's front end or backend shifts, which we account for in maintenance.

Native export

For a one-off, the app's transaction export and in-app tax tooling give a usable snapshot we can normalize without standing anything up.

For Trust Wallet specifically the address-and-indexer path is the one worth building on, because a self-custody balance has no other source of truth — it only ever lives on the chain. The aggregation-tier work is what we add when you need the figures to line up cent-for-cent with what the user reads in the app; native export is reserved for a single pull where a live sync would be overkill.

What lands in your hands

• An OpenAPI specification for a normalized endpoint set — /addresses, /balances, /transactions, /nft, /earn-positions — keyed by wallet or address.
• A protocol and resolution report: how xpub-to-address derivation runs per chain family, which indexers back each domain, and how the aggregation tier decodes transfers and prices assets.
• Runnable source for the core readers in Python or Node.js, including the per-protocol position decoders for Stablecoin Earn.
• Automated tests against known addresses with fixed historical state, so a regression in derivation or decoding is caught.
• Interface documentation and data-retention guidance written around read-only public-address access.

Each piece is tied to a real surface above — the position decoders exist because Morpho and Aave report a deposit differently on-chain, the derivation code exists because Bitcoin and Ethereum address discovery are not the same problem.

Code sketch

Illustrative only — exact indexer endpoints and field names are confirmed during the build. The shape shows the read path for a single consented xpub.

# read-only: resolves addresses from an xpub, never a private key
def portfolio(xpub, chains):
    addrs = derive_addresses(xpub, gap_limit=20)   # UTXO chains: scan to gap limit
    out = {"balances": [], "earn": []}
    for chain in chains:                            # e.g. ethereum, bsc, arbitrum, base
        for a in addrs[chain.family]:
            for tok in indexer.tokens(chain, a):    # spot token balances
                out["balances"].append({
                    "chain": chain.id, "address": a,
                    "token": tok.symbol, "amount": tok.amount,
                    "decimals": tok.decimals
                })
            # Stablecoin Earn: read protocol position, not just idle balance
            for p in EARN_PROTOCOLS:                 # morpho, aave, compound, venus...
                pos = p.position(chain, a)
                if pos and pos.principal > 0:
                    out["earn"].append({
                        "protocol": p.name, "asset": pos.asset,
                        "principal": pos.principal, "accrued": pos.accrued
                    })
    return out

# 429 / node failover is expected at scale — retry with backoff,
# rotate RPC endpoints, and apply per-chain confirmation thresholds.
        

How a position comes back

One normalized record, so an Earn deposit and an idle token read the same to your code:

{
  "wallet": "user-ref-001",
  "chain": "arbitrum",
  "kind": "earn_position",
  "protocol": "morpho",
  "asset": "USDC",
  "principal": "1500.00",
  "accrued": "7.42",
  "as_of_block": 0,        // pinned per read for reproducibility
  "confirmations": 64
}
        

Things we plan for up front

• We never ask for a seed phrase or private key. The build runs on public addresses or an xpub, read-only, so the integration physically cannot sign or move funds — that boundary is part of how we scope it, not an afterthought.
• We design the sync to be reorg-aware. Recent blocks can be replaced, so balances are read against confirmation thresholds and short reorgs trigger a targeted backfill rather than a wrong number that later corrects itself.
• We handle address discovery per chain family: a gap-limit scan from the xpub for UTXO chains like Bitcoin, direct per-address reads for account-model chains like Ethereum. Miss this and a wallet looks emptier than it is.
• We map Stablecoin Earn protocol by protocol — Morpho, Aave, Compound, Venus, Spark, Angle, Kiln — because each reports principal and yield through different contracts, and a position read as a plain token balance understates what the user actually holds.
• We wire the aggregation-tier reads behind a check that flags when decoded output drifts from on-chain truth, so a quiet change in how transfers are decoded shows up in maintenance instead of in your data.

Consent and the data law that applies

Trust Wallet is self-custodial and, per its listing, collects no personal data — so there is no bank-style consent regime to ride here and no central account to authorize against. The dependable basis is narrower and cleaner: the wallet owner authorizing the use of their own public addresses, read-only. Where any personal data is attached on your side, GDPR and CCPA principles govern it; the integration is built to touch the minimum, keep no private keys, and log what was read and when.

For the EU, self-custody wallets largely sit outside the custody obligations that bind crypto-asset service providers under MiCA, since no third party ever holds the user's keys. We keep consent records for the address authorization, run under NDA where the engagement calls for it, and scope retention to what your use actually needs.

Cost and how the work runs

Source-code delivery starts at $300, and you pay after we hand it over and you have run it against your own addresses and are satisfied — you get the runnable readers, the OpenAPI spec, tests and the protocol report to keep. The other way is the pay-per-call hosted API: we run the endpoints, you call them and pay only for the calls, with nothing upfront. Either way the build cycle is one to two weeks. Tell us the wallet data you need and how you want to consume it, and we sort the indexer access and the rest with you — start at /contact.html.

Interface the data is read against

Screens from the app's store listing, for reference to the surfaces above.

Wallets that raise the same integration question

Same category, same underlying pattern — addresses on public chains rather than a hosted account ledger. Useful when one feed needs to span more than one wallet.

• MetaMask — EVM-focused self-custody wallet and dApp gateway; data is on-chain per address, read the same way.
• Coinbase Wallet — self-custody wallet distinct from the Coinbase exchange account; holds keys on-device, assets on-chain.
• Exodus — multi-chain desktop and mobile wallet; balances and history reconstructed from addresses.
• Ledger Live — companion app for Ledger hardware keys; portfolio view built from public addresses.
• SafePal — hardware and software wallet with multi-chain support and on-chain asset state.
• Zerion — portfolio-first wallet that already aggregates DeFi positions across chains by address.
• MyEtherWallet — long-standing Ethereum-ecosystem wallet keyed to user addresses.
• Binance Wallet — self-custody Web3 wallet with tight access to Binance liquidity; on-chain holdings.
• Atomic Wallet — multi-asset wallet with built-in swaps; state read from the chains it supports.
• Coinomi — multi-chain wallet covering a wide token set, all address-keyed.

Questions integrators ask about this one

Do you ever need a user's seed phrase or private keys?

No. The integration runs on public addresses or an extended public key (xpub) exported with the wallet owner's consent, read-only. Signing capability is never requested and never in scope, so the feed can read balances and history but cannot move funds.

How do you keep balances consistent across 100+ chains?

We query each chain through RPC nodes and indexers and apply per-chain confirmation thresholds, with reorg-aware backfill so a balance does not flicker when a recent block is replaced. UTXO chains like Bitcoin get gap-limit address discovery from the xpub; account-model chains like Ethereum are read per address.

Can you capture Stablecoin Earn yield positions, not just spot balances?

Yes. Stablecoin Earn deploys USDT, USDC, DAI and USDA into onchain protocols such as Morpho, Aave, Compound, Venus, Spark, Angle and Kiln across Ethereum, BSC, Arbitrum and Base. We read each protocol's position contracts so the feed shows deposited principal and accrued yield, not only the wallet's idle token balance.

If we only need a one-time CSV of a wallet's transactions, is that simpler than a live feed?

It is. Trust Wallet exposes transaction export and in-app tax tooling, and for a single snapshot we can resolve the addresses and produce a normalized CSV without standing up a hosted endpoint. A live feed only makes sense when you need ongoing sync.

What was checked, and against what

Notes drawn from the app's own store listing and developer material, plus the Stablecoin Earn announcements naming the integrated protocols and chains. Verified against: the Trust Wallet developer documentation and its open-source Wallet Core library for the key-derivation and multi-chain model; the Stablecoin Earn page and Kiln's integration write-up for the protocols and supported chains.

Mapped by the OpenBanking Studio integration desk, June 2026.