Reading balances and transfer history out of Cwallet

Cwallet holds per-user balances for what its Play Store listing describes as 1,000+ tokens across more than 60 chains — Bitcoin, Ethereum, USDT on TRON, Solana, XRP and the rest — alongside a transaction record, swap history and Earn positions that only exist inside its backend. For an integrator the useful split is obvious early: some of that ledger is settled on public blockchains and can be read without touching the app, and some of it is private to Cwallet's servers. A working integration treats those two halves differently.

The route we would actually run pairs two things. App-internal records — swaps, Earn interest, Telegram payouts, card spend — come from the authenticated client traffic against a consenting account. Chain-settled balances and transfers we read straight off the public ledgers for the addresses that account controls. Each half covers the other's blind spot, and the on-chain half keeps working even when the app ships a new build.

Account data surfaces inside Cwallet

Mapped from the app's own description of its wallet, swap, Earn and Telegram modules. Granularity below reflects what a logged-in user sees, not a guess at internal storage.

Getting to the data: routes that fit a custodial multi-chain wallet

1 · Authorized protocol analysis of the consenting client

The mobile and web clients talk to Cwallet's backend over authenticated JSON calls for the wallet summary, the per-asset transaction list, swap history and Earn positions. We capture that traffic against an account the client consents to, document the request shapes and auth chain, and rebuild it as a typed client. Reach: everything the logged-in user can see, including the app-only records that never touch a chain. Effort is medium; durability is tied to the client version, so app updates trigger a re-validation pass. Access to a consenting account is arranged with you during onboarding.

2 · Direct on-chain reconciliation

Deposit and withdrawal addresses in Cwallet are real addresses on public networks. For an address the account holder controls, confirmed balances and inbound/outbound transfers are readable from a block explorer or a node — no app session required. This is the most durable path for chain-settled value and a strong cross-check on route 1. The caveat we plan around: custodial deposits can land in pooled or omnibus addresses that do not map one-to-one to a single user, so we reconcile against the app-side records rather than assuming a clean per-user address.

3 · User-consented portal session and native export

The authenticated web portal at my.cwallet.com renders the same balances and history and, where the account exposes it, a transaction export. With the account holder consenting, we drive that session — passkey and 2FA handled together with them — and use any native export as a reconciliation baseline rather than the primary feed, since exports tend to lag and summarize.

For most engagements the practical answer is route 1 and route 2 working together: the client traffic gives you swaps, Earn and card records that exist nowhere else, while on-chain reads give you a tamper-evident view of the chain-settled balances that survives app changes. Route 3 is worth wiring in only when a client wants a human-auditable export alongside the programmatic feed.

A worked example: balance summary then transfer list

Illustrative shapes, confirmed and pinned during the build against a consenting account — field names and the exact auth header are settled from captured traffic, not assumed here.

# 1) Establish an authenticated session (passkey/2FA handshake mapped once,
#    token refresh handled on expiry — arranged with the account holder).
POST /api/v1/auth/session
  -> { "access_token": "...", "expires_in": 3600, "refresh_token": "..." }

# 2) Wallet summary across chains, tagged by wallet type.
GET /api/v1/wallet/summary
Authorization: Bearer <access_token>
  -> { "wallets": [
       { "type": "custodial",     "chain": "TRON",     "asset": "USDT",
         "balance": "1840.55", "address": "T..." },
       { "type": "non_custodial", "chain": "ETHEREUM", "asset": "ETH",
         "balance": "0.4172",  "address": "0x..." }
     ] }

# 3) Per-asset transfer history (paginated; cursor echoed back).
GET /api/v1/wallet/transactions?asset=USDT&chain=TRON&cursor=0
  -> { "items": [
       { "hash": "...", "direction": "in", "amount": "500.00",
         "ts": 1733500800, "status": "confirmed" }
     ], "next_cursor": "..." }

# Then: for every chain-settled row, verify hash + amount against the
# public explorer for that network. Mismatch -> flag, never silently trust.
def reconcile(tx, chain_client):
    onchain = chain_client.get_tx(tx["hash"])
    return onchain and onchain.amount == tx["amount"] and onchain.confirmed
      

What lands in your repo

Tied to Cwallet's actual surfaces, not a generic wallet bundle:

• An OpenAPI/Swagger spec covering the wallet summary, transaction list, swap history and Earn endpoints as captured.
• A protocol and auth-flow report: the session handshake, token refresh, and how the passkey/2FA step fits an unattended sync.
• Runnable source (Python and Node.js) for the balance, transaction and swap pulls, plus the on-chain reconciliation client per network.
• A normalized schema that puts custodial holdings, non-custodial holdings and chain-read balances on one timeline.
• Automated tests against recorded fixtures, including the omnibus-address and confirmation-lag edge cases.
• Interface documentation and data-retention guidance for handling wallet data under the account holder's consent.

Authorization, consent and data handling

A custodial crypto wallet sits outside the bank-account open-banking schemes, so there is no AIS consent rail to ride. The dependable basis is the account holder's own authorization to reach their data — granted to you, exercised by us on their behalf, and logged. Where users fall under GDPR or an equivalent data-protection law, the wallet records (balances, addresses, transaction parties) are personal data, so we minimize what is pulled to the fields a use case needs, keep consent and access records, and work under NDA where the engagement calls for it. On-chain reads carry their own nuance: a public ledger is already public, but linking an address to a named person is the sensitive step, so address-to-identity mappings are held to the same minimization rule as the app-side data.

Engineering details we plan around

• Two wallet contexts, kept separate. Cwallet exposes a custodial side and a non-custodial side that the vendor describes as using multi-party computation. We tag every holding by wallet type so a custodial USDT balance and a self-custody ETH balance never get merged into a single misleading figure.
• Pooled custodial addresses. Custodial deposits can share an omnibus address, so an on-chain balance for that address is not one user's balance. We design the reconciliation to lean on the app-side per-user records for custodial assets and reserve direct on-chain reads for addresses that genuinely map to the account.
• Per-chain quirks. Memo/tag chains (XRP, some Stellar and TRON flows) and varying confirmation depths mean a naive "got the transfer" check is wrong for several of the 60+ networks. The reconciliation client carries per-chain confirmation thresholds and memo handling rather than one rule for all.
• Front-end churn. When the app updates its client, request shapes can shift. We build a re-validation step into maintenance so a changed field surfaces as a test failure, not a silent gap in the feed.

Screens from the app

Public Play Store screenshots, useful for seeing which surfaces carry the records above. Select to enlarge.

Keeping the feed accurate

Two things drift if you ignore them. Client versioning, handled by the re-validation pass above. And confirmation lag — a chain-settled transfer is real only after enough confirmations, which differs per network, so the reconciliation client waits on per-chain thresholds before marking a transfer final. Sessions get refreshed before they expire so an unattended sync does not stall mid-run. The result is a feed where app-side records and on-chain truth agree, and disagreements are flagged rather than averaged away.

Other wallets in the same integration space

Teams aggregating wallet data usually need more than one source. These sit in the same category as Cwallet and come up alongside it; named here for ecosystem context, not ranked.

• Trust Wallet — self-custody multi-chain wallet; balances and history are read from the keys and public chains the user holds.
• MetaMask — EVM-focused non-custodial wallet; account data follows the connected addresses on-chain.
• Exodus — multi-asset desktop and mobile wallet with portfolio and swap history.
• Atomic Wallet — non-custodial multi-coin wallet with built-in exchange records.
• SafePal — hardware and software wallet combining on-device keys with app-side transaction views.
• Phantom — Solana-first wallet now spanning several chains; balances and activity read on-chain.
• Coinbase Wallet — self-custody wallet distinct from the exchange, holding per-user addresses and dapp activity.
• OKX Wallet — multi-chain wallet with swap and on-chain history surfaces.
• Zengo — keyless MPC wallet, conceptually close to Cwallet's non-custodial side.
• Blockchain.com — wallet plus exchange, mixing custodial balances with on-chain reads.

Questions integrators ask about Cwallet

Which Cwallet records come from the app and which can be read straight off-chain?

Chain-settled deposits, withdrawals and on-chain balances sit on public ledgers, so for an address the account holder controls we read them from a block explorer or node independently of Cwallet. App-internal records — swap legs, Earn accruals, Telegram tips, Cozy Card spend — exist only inside Cwallet's backend, so those come from the authenticated client traffic. Most builds combine both.

Can you separate custodial balances from the non-custodial MPC wallets in Cwallet?

Yes. Cwallet runs a custodial side and a non-custodial side that, as the vendor describes it, uses multi-party computation. The two are different account contexts in the client responses, so we tag each holding by wallet type during the mapping rather than merging them into one balance.

How do passkey login and two-factor authentication affect an automated pull from a consenting account?

They shape the session handshake, not whether the data is reachable. With the account holder consenting, we map the login and token-refresh chain once, then keep the session alive and re-authenticate on expiry. The challenge step is handled with the account holder during onboarding; it does not block an unattended sync afterward.

Do Cwallet swap and Earn records carry enough detail for tax or profit-and-loss reporting?

The swap records expose the pair, executed rate, fee and timestamp, and Earn positions report principal and accrued interest, which Cwallet describes as calculated hourly. That is enough to build a cost-basis and realized-gain feed; we normalize it into a flat schema so it lines up with on-chain transfers on the same timeline.

Sources and review notes

This mapping was put together on 7 June 2026 from the app's own Play Store listing, Cwallet's wallet and feature pages, and general references on the MPC custody model it uses. No private credentials were accessed in preparing it; the field shapes above are pinned during a paid build, not asserted from these public pages. Citations:

• Cwallet - Secure Crypto Wallet on Google Play
• Cwallet web wallet — store, swap and trade
• Cwallet custodial wallet overview
• Cwallet non-custodial (MPC) wallet

Compiled by the OpenBanking Studio integration desk · 7 June 2026.

One last practical note on cost and timing. A focused build — balances, transactions and swap history with on-chain reconciliation — runs on a 1–2 week cycle. You can take it as runnable source code from $300, paid only after delivery once it works to your satisfaction, or call our hosted endpoints and pay per call with nothing upfront. Tell us the app and what you need from its data; we handle access, mapping and compliance from there. Start a project on the contact page.