Getting a unified feed of MyTonWallet balances and transfers

Every MyTonWallet account is keyed to on-chain addresses on TON, TRON and Solana, so the balances, jettons and transfer history a third party usually wants are already sitting in public ledgers. What the chain does not hand you is the part the wallet actually builds: one normalized, multi-chain, per-account view with token symbols resolved, NFT collectibles grouped, staking positions attached and spam filtered out. That assembled view is the integration target here, and it is reconstructed from public chain data plus a consented session — not from anything the developer holds, because the wallet is self-custodial and holds nothing.

The app describes itself as a feature-rich wallet for TON, TRON and Solana with multi-account support, multi-send, Telegram Gifts and other collectibles, and TON DNS / Sites / Proxy; recent builds add several EVM chains as well, per its own site. For an integrator the useful framing is simpler. There are addresses, there are public ledgers behind them, and there is an authorized way to bind a session to those addresses and read everything across the three main chains into one shape.

Bottom line: the heavy data is on-chain and reachable through stable indexers, so the bulk of a build is normalization rather than scraping. The work is anchored on indexer reads, because that is where balances, jettons, NFTs and transfers genuinely live; TON Connect is added when you need the account holder to prove an address and authorize the session; and protocol analysis of the client only earns its place when you want app-side extras such as saved labels or the in-app swap routing that never reach the chain in a readable form.

Where MyTonWallet keeps each kind of record

The table maps what the app shows a user to where that data actually originates, how granular it is, and what an integrator does with it.

Three authorized ways into the data

1 — Blockchain indexer reads

The core route. The wallet's own configuration points at Toncenter and TonAPI for TON, a Solana RPC (Helius in its sample config) for the Solana side, and TRON infrastructure — confirmed in the open-source .env.example. We query those same indexers by address for balances, jettons, NFTs and transaction history. Reach is essentially everything on-chain; durability is high because public-ledger APIs are stable and versioned. Indexer keys and rate-limit headroom are arranged as part of the build, not asked of you up front.

2 — TON Connect session with ton_proof

When the integration needs the account holder to prove an address or authorize sends, we use TON Connect 2.0. The wallet returns a ton_proof — an Ed25519 signature binding the address, your app domain, a timestamp and a server nonce — which the backend verifies. This is the documented, open ecosystem protocol the wallet already speaks, so it is durable and does not depend on any private surface.

3 — Authorized protocol analysis of the client

A handful of surfaces are assembled client-side and never land on-chain in readable form — saved address-book labels, anti-spam preferences, the in-app Agent, swap-route choices. For these we observe the app talking to its backend (its sample config names an Agent API) under your authorization and a consenting account, and document the calls. Reach is the app-assembled extras; durability is medium, since a client build can move things, so we keep a check that re-runs when the app version changes.

A native account backup/export also exists for the user and can seed a build where a consenting holder supplies it. For most projects the indexer reads carry the weight and TON Connect supplies the consent and identity layer; protocol analysis is brought in only for the app-side pieces that justify it.

Reading a wallet account end to end

Illustrative Python for the TON side — endpoints and exact field names are confirmed against the live indexers during the build. The providers below are the ones the wallet itself uses, per its .env.example.

# TON side of a MyTonWallet account, via TonAPI (provider used by the wallet)
import requests

TONAPI = "https://tonapi.io/v2"

def ton_portfolio(address: str) -> dict:
    acct    = requests.get(f"{TONAPI}/accounts/{address}").json()
    jettons = requests.get(f"{TONAPI}/accounts/{address}/jettons").json()
    nfts    = requests.get(f"{TONAPI}/accounts/{address}/nfts?limit=100").json()
    return {
        "ton_balance": acct["balance"],            # nanotons (1 TON = 1e9)
        "status":      acct["status"],             # active | uninit | frozen
        "jettons":     [(j["jetton"]["symbol"], j["balance"])
                        for j in jettons["balances"]],
        "collectibles":[n["address"] for n in nfts["nft_items"]],
    }

# Prove the holder controls that address (TON Connect ton_proof):
#   message = "ton-proof-item-v2/" + address + app_domain + ts + payload
#   signed  = sha256( 0xffff + "ton-connect" + sha256(message) )
#   accept  if Ed25519(signature, signed, wallet_pubkey) and ts within window
#   and the address re-derived from wallet stateInit matches the reported one

Two practical notes ride along with that snippet. Jetton balances are not held at the owner address — each lives in a per-jetton wallet contract — so a balance read resolves the owner-to-jetton-wallet mapping first. And TON has eventual finality at the masterchain, so a sync stamps each pull with a seqno and re-polls rather than trusting a single shot.

Folding TON, TRON and Solana into one record

The deliverable is a single normalized shape, not three chain-specific dumps. Roughly:

{
  "account": "mytonwallet:primary",
  "chains": {
    "ton":    { "native": "TON", "balance": "...", "jettons": [...], "nfts": [...] },
    "tron":   { "native": "TRX", "balance": "...", "trc20":  [...] },
    "solana": { "native": "SOL", "balance": "...", "spl":    [...] }
  },
  "staking": [ { "pool": "...", "type": "nominator|liquid", "principal": "...", "rewards": "..." } ],
  "as_of": "<masterchain seqno / solana slot>"
}

Decimals, address formats and token symbols are reconciled per chain before they meet in that record, which is most of the real work.

What lands in your repo

Each piece is tied to the surfaces above, not a generic checklist:

• An OpenAPI/Swagger spec for a normalized wallet-data service — balances, jettons, NFTs, transfers, staking, keyed by logical account.
• A protocol and auth-flow report covering the TON Connect ton_proof chain and indexer authentication, written against this wallet's providers.
• Runnable Python or Node source for the key reads: portfolio, jetton wallets, NFT items, transaction history and staking positions.
• Automated tests that run against a consenting testnet account, so the reads are checked, not just described.
• Interface documentation plus compliance and data-retention guidance for the on-chain and app-side data.

Consent and the non-custodial line

Self-custody changes the legal footing in a helpful direction. Because MyTonWallet generates and stores keys on the user's device and never controls funds, a software wallet of this kind generally sits outside the Crypto-Asset Service Provider licensing in the EU's MiCA framework, per ESMA's own materials on who counts as a CASP. So the dependable basis for the work is twofold: data that is already public on-chain, and the account holder's explicit authorization for anything tied to their session or their app-side state. Consent through TON Connect is scoped and revocable — a session can be dropped and a ton_proof expires within its time window. For any personal data that an app-side surface processes, we work under GDPR: consent records kept, access logged, data minimized to what the integration needs, and NDAs in place where the engagement calls for them.

Things we handle on the way

A few specifics about this wallet that shape the build, all of which we take on rather than hand back:

• One logical account resolves to different address formats per chain — TON bounceable and non-bounceable base64url, TRON base58, Solana base58 — so we normalize address handling so the same account reconciles cleanly across all three.
• Toncenter is rate-limited (roughly one request per second without a key, per its docs), so we design batching and key rotation and pace the sync to TON's finality model instead of hammering the endpoint.
• Jetton, TRC-20 and SPL tokens each carry their own decimals and contract semantics, so we resolve symbols and scaling per token before anything is summed or displayed.
• The app-side surfaces depend on a client build that can change, so we keep a re-validation check tied to the app version and arrange testnet or consenting-account access with you during onboarding.

Screens we mapped against

Store screenshots used while sketching the data surfaces. Select one to enlarge.

Other wallets in the same ecosystem

Same-category wallets a unified integration often has to sit alongside. Listed for context, with no ranking implied:

• Tonkeeper — a widely used TON wallet with sending, swaps, staking and jetton/NFT management; a common second wallet to reconcile against.
• Tonhub — non-custodial TON wallet focused on storing, sending and staking Toncoin.
• Wallet in Telegram (TON Space) — the self-custody wallet inside Telegram, tied closely to Mini Apps and the TON ecosystem.
• Trust Wallet — multichain wallet that holds TON alongside many other chains, often the aggregate view a treasury wants.
• Gem Wallet — open-source multichain wallet covering TON among others.
• Ledger — hardware wallet whose TON accounts surface the same on-chain balances and history.
• SafePal — hardware and software wallet supporting TON and multiple other networks.
• Tangem — card-based hardware wallet that stores TON keys for self-custody.

Questions integrators ask about MyTonWallet

Does MyTonWallet hold this data, or does it live on-chain?

Most of it lives on public ledgers. Balances, jettons, NFTs including Telegram Gifts, swaps and transfer history sit on TON, TRON and Solana, and MyTonWallet assembles them into one normalized per-account view. A few surfaces are app-side state — saved address-book labels, anti-spam settings and the in-app Agent — and those we read only from a consenting account.

How do you confirm an address really belongs to the account holder?

Through TON Connect's ton_proof. The wallet signs a server-issued nonce bound to your domain and a timestamp with its Ed25519 key, and the backend re-derives the address from the wallet state-init and verifies the signature. That ties a session to an address without ever touching the recovery phrase.

Can the TON, TRON and Solana balances come back as one feed?

Yes. We resolve each chain on its own — Toncenter and TonAPI for TON, a Solana RPC such as Helius, a TRON node — then map jetton wallet contracts back to their owner and normalize tokens, decimals and address formats into a single schema keyed by logical account.

Does the wallet being non-custodial change the compliance side?

It simplifies it. Because the developer never holds keys or funds, a self-custody wallet generally falls outside MiCA's CASP licensing per ESMA, so the dependable basis for the work is the account holder's own authorization plus data already public on-chain. App-side personal data is handled under GDPR with consent records and data minimization.

What we checked

Mapped against the wallet's open-source configuration to confirm which indexers it actually calls, the TON Connect specification for the ton_proof flow, TonAPI's account reference for the read endpoints, and ESMA's MiCA materials for the self-custody scope question. Reviewed June 2026 by the OpenBanking Studio integration desk.

• MyTonWallet .env.example — the backend providers it uses (Toncenter, TonAPI, Solana RPC).
• TON Connect specification — the ton_proof structure and verification.
• TonAPI accounts reference — balance, jetton and NFT endpoints.
• ESMA — Markets in Crypto-Assets (MiCA) — CASP scope.

Getting it built

A working build here is a normalized multi-chain read service — TonAPI and Toncenter for TON, a Solana RPC for the Solana side, a TRON node, and ton_proof for identity — shipped with the endpoints, tests and protocol notes you need to run it yourself. Source-code delivery starts at $300, and you pay only after it is delivered and you are satisfied. If you would rather not host anything, the same reads are available as a pay-per-call hosted API with no upfront fee. Either way the cycle is one to two weeks. Tell us the wallet and what you want out of its data on the contact page and we will scope it from there.