Reaching the holdings, swaps and history inside IBVM Wallet

Four token networks sit behind one IBVM wallet screen: Bitcoin, Ethereum, Solana, and the IBVM Layer 2 itself, plus whatever swap assets a user has touched. Per the app's store listings, holdings, swaps and DeFi activity all live inside a self-custody design where the private keys never leave the phone. That single fact shapes every decision below. The financial record an integrator wants is partly written on public chains and partly held inside the app's own backend, and none of it is reachable by asking for a password.

Bottom line: most of the value here is public chain data tied to a user's addresses, which makes a watch-only read both clean and durable. The pieces that aren't on a chain — the airdrop ledger, the in-app swap log, the dApp catalog — sit behind the app's session and need an authorized look at its traffic. We build both halves and hand them back as one read API.

What the wallet actually holds

Each row maps a surface in the app to where it originates and what an integrator does with it. The shape reflects this app's screens, not a generic wallet checklist.

Authorized routes to the wallet's data

Public chain RPC and explorer indexing

Given a user's addresses or extended public keys, balances and full transaction history for Bitcoin, Ethereum, Solana and the IBVM Layer 2 are read straight from chain indexers and RPC nodes. This is the most durable path because it does not depend on the app's UI staying still. We stand up the indexer and RPC access and the address-discovery logic as part of the build.

Authorized interface integration / protocol analysis

The surfaces that never hit a public chain — swap quotes and history, the rewards and airdrop ledger, the dApp store catalog, the in-app price feed — are reached by observing the app's own traffic to its backend under the customer's authorization. We map the session and token flow against a consenting account during onboarding. Durability tracks the app's release cadence, which we plan for.

User-consented watch-only enrollment

The user shares extended public keys or individual addresses, never the seed. From those we derive the full holding and history set read-only. Nothing secret is requested or stored, which keeps the privacy posture simple.

Native backup / export

Where the app exposes its own backup or address export, that becomes a fallback for enrollment data. It is a convenience to lean on, not where the integration's weight sits.

For IBVM specifically, the dependable core comes from reading the four chains directly with a user's watch-only keys; we reach for protocol analysis only where a surface exists solely inside the app. That split keeps most of the financial record independent of how often the app ships an update — a real advantage for a wallet whose underlying network is this new.

What lands in your repo

• OpenAPI / Swagger spec for a unified read API: /holdings, /transactions, /swaps, /rewards across the four networks.
• Protocol & auth-flow report describing how the app authenticates to its backend (the token / session chain captured during the build) and how the watch-only on-chain reads are structured.
• Runnable source in Python and Node.js for the watch-only aggregator and the app-surface capture, with recorded fixtures.
• Automated tests per chain, run against those fixtures so a network change surfaces as a failing test.
• Interface documentation plus data-retention and minimization guidance that mirrors the app's stated no-collection posture.

A watch-only read across four chains

Illustrative — endpoint names and the IBVM L2 chain id are confirmed during the build, not asserted here.

# Watch-only holdings across the networks IBVM Wallet shows.
# No seed phrase: the user supplies extended public keys / addresses only.

def holdings(xpubs, addresses):
    out = []
    # Bitcoin: derive receive/change addresses from the xpub, sum UTXOs
    for addr in derive(xpubs["btc"], gap_limit=20):
        out += utxos(indexer="btc", address=addr)      # id, value, confirmations
    # Ethereum + Solana: account-model balances
    out.append(rpc("eth", "eth_getBalance", [addresses["eth"], "latest"]))
    out.append(rpc("sol", "getBalance",     [addresses["sol"]]))
    # IBVM Layer 2: token balance via the L2 RPC (method confirmed at build time)
    out.append(rpc("ibvm", "eth_call", [erc20_balanceOf(addresses["ibvm"])]))
    return normalize(out)   # -> {network, asset, amount, as_of, source}

# App-only surfaces (rewards ledger, swap log) come through the authorized
# session mapped at onboarding, then map to the same schema.
# 4xx/5xx and reorg/confirmation gaps are retried with backoff.

The normalized record is deliberately small, so a Bitcoin UTXO sum and an IBVM token balance read the same downstream:

{ "network": "ibvm-l2", "asset": "IBVM",
  "amount": "0.0", "as_of": "<iso8601>",
  "source": "watch-only" }

MiCA posture and the consent basis

The relevant European frame is MiCA — Regulation (EU) 2023/1114. Per ESMA, the rules for crypto-asset service providers under Title V applied from 30 December 2024, with the EU-wide transitional window closing on 1 July 2026. Recital 22 carves out "fully decentralized" services, but ESMA has flagged that there is no precise test for that label and Level 3 guidance is still expected. A self-custody wallet that has an identifiable publisher and a managed token can still fall in scope, so we work on the conservative side rather than assume the carve-out.

The dependable basis we build on is the user's own authorization. They hold the keys and consent to read-only access, which is exactly what makes watch-only enrollment clean. Consent scope stays read-only and time-bounded; a user revokes simply by rotating to new addresses. We log access, keep consent records, and minimize what is stored — consistent with the app's own "does not collect any data" statement in its App Store privacy section. An NDA is in place where the engagement calls for one.

Engineering realities we account for

These are the parts of an IBVM integration that need real judgment, and they are handled on our side as part of the work.

• No keys, ever. Because the wallet is non-custodial, the whole integration is watch-only: xpubs and addresses go in, balances and history come out. We design enrollment so no secret material is requested or retained.
• Three balance models, one schema. Bitcoin's UTXO set, the account balances of Ethereum and Solana, and the IBVM Layer 2's own semantics do not line up by default. We normalize confirmation and finality rules so a pending BTC transaction and a finalized SOL transaction are comparable in the same view.
• A young Layer 2. IBVM's network is newly launched — crypto.news reported a token generation event and a one-million-user figure ahead of it. Its RPC schema and the IBVM token contract can still move, so we version the integration against the chain and run fixture checks that fail loudly on an endpoint or contract migration instead of drifting quietly.
• App-only surfaces. The rewards ledger and swap log sit behind the app's session rather than on a public chain; we map that auth flow with a consenting account during onboarding so those records join the same output.

Interface evidence

Store screenshots we reviewed while mapping the surfaces above. Tap to enlarge.

What we checked

Reviewed on 11 June 2026: the Google Play and Apple App Store listings for com.ibvm.wallet (supported assets, category, and the App Store privacy note), the IBVM project site for the Layer 2 framing, and recent coverage of the network's token event for its status. The IBVM token contract address and the app backend's exact endpoints are not publicly disclosed in a form we would assert here; both are confirmed during the build. Citations: Google Play listing, Apple App Store listing, ibvm.io, crypto.news on the IBVM token event.

IBVM Wallet mapping — OpenBanking Studio integration desk, 11 June 2026.

Where IBVM Wallet sits among self-custody apps

Teams integrating IBVM usually want one read API that also spans the other wallets their users hold. The same watch-only and protocol-analysis approach applies across these:

• MetaMask — Ethereum and EVM-chain accounts, token balances and dApp connections, addressable by xpub and RPC.
• Trust Wallet — broad multi-chain holdings including Bitcoin, Ethereum, BNB Chain and Solana across many networks.
• Phantom — Solana-first, with Ethereum and Bitcoin support; balances and swap activity per address.
• Coinbase Wallet — self-custody balances across Ethereum, EVM chains and Solana, separate from the Coinbase exchange account.
• Exodus — multi-chain portfolio and built-in swap records spanning Bitcoin, Ethereum and Solana.
• Atomic Wallet — multi-network balances and in-app exchange history across Ethereum, Solana and others.
• Cake Wallet — Monero, Bitcoin, Ethereum and Solana holdings with a privacy-first design.
• Ledger Live — companion app surfacing balances and history for assets held on Ledger hardware.

Questions integrators ask about IBVM Wallet

Can you integrate IBVM Wallet without the seed phrase?

Yes. The build is watch-only — you or your user supplies extended public keys or individual addresses, and we read balances and transaction history from the four networks without ever touching the private keys.

How do you reconcile the IBVM Layer 2 token with the Bitcoin, Ethereum and Solana holdings?

Each network is read on its own terms — UTXOs for Bitcoin, account balances for Ethereum and Solana, and the IBVM Layer 2 via its own RPC — then normalized into one schema with a consistent as-of timestamp and confirmation state.

Can you capture the airdrop rewards and in-app swap records that are not on the main chains?

Those live inside the app's own backend rather than on a public chain, so we read them through an authorized session mapped with a consenting account during onboarding, and fold them into the same normalized output.

If we operate this for EU users, what regulatory frame applies?

MiCA is the relevant EU regime, and we build on the user's own read-only consent as the dependable basis; access, logging and any NDA are arranged with you as part of the engagement, and delivery runs one to two weeks.

Getting a build started

A working IBVM read API lands in one to two weeks. You can take it as source-code delivery from $300 — the runnable aggregator, the protocol and auth-flow report, the per-chain tests and the interface docs, paid only after delivery once you're satisfied — or skip hosting and call our endpoints on a pay-per-call basis with no upfront fee. Either way you give us the app name and what you want out of its data; we arrange access, the watch-only enrollment and compliance with you. Tell us which surfaces matter at /contact.html.