Ballet Crypto keeps no account, so its data is the chain and the price feed

Scan the QR code on a Ballet cold-storage card and the app starts working with no account, no login and no KYC, as the app's own listing and Ballet's documentation describe it. That one design decision sets the whole integration. There is no Ballet sign-in holding the balances. The record sits on public blockchains, keyed to the deposit address printed on each card, with a market-data layer on top that produces the real-time portfolio figure the app shows.

So a build here is two read paths joined. Index the chains for the card's addresses, then match the valuation the app displays. The encrypted private key never enters that picture.

The bottom line for anyone planning this: the data you want — current balance, full transaction history, a fiat portfolio total — is already public and permanent on the chains the card uses. The work is not extraction from a guarded system. It is correct address resolution, faithful valuation, and a clean read-only boundary that never touches key material. We would build the on-chain path as the backbone because it does not decay when the app updates, and layer the protocol-analysis path on top so the portfolio number lands where a holder expects it.

Where the holdings record actually lives

Each row below maps a data domain to where it originates inside Ballet Crypto, the granularity an integrator gets, and what it is good for.

Authorized ways in to balances and history

Two routes carry this work, with a third that removes manual entry and a thin fallback. Each is run under the card owner's authorization; access is arranged with the client during onboarding.

On-chain indexing, keyed to owner-shared addresses

Reachable: every balance and the complete, permanent transaction record for each activated asset. Effort: moderate — per-chain indexers, an Electrum or BlockBook-class server for Bitcoin and JSON-RPC for the EVM chains (Ethereum, Polygon, BNB Chain). Durability: the highest available, because the ledger is public and does not depend on Ballet's front end. This is the route we treat as the backbone.

Protocol analysis of the app's price and activation traffic

Reachable: the exact valuation logic and the activated-asset and fee metadata the app itself uses. Effort: low to moderate — observe and document the price and activation calls the app makes under the owner's authorization. Durability: medium, since those calls can move between releases; part of the build is a small monitor that diffs the app's price and activation calls after each new version, so a moved endpoint surfaces before the feed goes stale. Layering this on top of the on-chain path is what makes the portfolio total agree with the in-app figure.

User-consented public-key or address access

The card owner shares the public deposit address or extended public key per card, which removes manual address entry and lets the address set resolve automatically. Read-side only. The private key and passphrase are never part of it.

Native in-app export, as a fallback

Where the app surfaces a shareable transaction view, that is captured as a low-effort safety net rather than a primary source.

What the read path looks like in code

Illustrative, confirmed in shape during the build. Inputs are public addresses the card owner shares — never the BIP38-encrypted key or the card passphrase.

# Rebuild a Ballet card portfolio from public data only
GET /v1/portfolio?card=BALLET-<serial>

# resolves the activated-asset address set for that card:
#   [ {asset:"BTC",   addr:"bc1q..."},
#     {asset:"ETH",   addr:"0x9a..."},
#     {asset:"MATIC", addr:"0x9a..."} ]   # Polygon reuses the secp256k1 addr

for a in assets:
    bal[a]   = indexer(a).balance(addr)          # Electrum / BlockBook / RPC
    txs[a]   = indexer(a).history(addr, limit=200)
    quote[a] = price_source.spot(a, "USD")       # pinned to the app's source

value_usd = sum(bal[a] * quote[a] for a in assets)

# 200 OK
{ "card": "BALLET-…", "as_of": "2026-05-18T00:00:00Z",
  "assets": [ { "asset": "BTC", "balance": "0.5031",
                "usd": "…", "confirmed": true, "tx_count": 12 } ],
  "portfolio_usd": "…" }

# 409  asset shown in-app but not yet activated server-side
# 422  address supplied is not derivable to a tracked chain
      

What a build hands you

Each deliverable ties to a real surface of this wallet, not a generic template:

• An OpenAPI specification for the unified balance, history and portfolio endpoints, modelled on the per-card, per-asset structure above.
• A protocol and data-flow report covering the app's price and activation calls and how the card's deposit addresses resolve to chains.
• Runnable Python or Node.js source for the indexer adapters (Bitcoin plus the EVM chains) and the balance-times-quote valuation join.
• Automated tests with recorded per-chain fixtures, including the activated-but-empty and multi-card cases.
• Interface documentation, and data-handling notes that state the read-only boundary in writing.

A normalized shape for multi-card holders

Ballet holders frequently own more than one card, so the delivered model collapses them into one object:

{
  "holder_ref": "opaque-id",
  "cards": [
    { "serial": "BALLET-…", "activated": ["BTC","ETH","MATIC"],
      "assets": [
        { "asset":"BTC", "chain":"bitcoin",
          "address":"bc1q…", "balance":"0.5031",
          "tx_count":12, "usd":"…" },
        { "asset":"MATIC", "chain":"polygon",
          "address":"0x9a…", "balance":"840.0", "usd":"…" }
      ]}
  ],
  "portfolio_usd": "…",
  "as_of": "2026-05-18T00:00:00Z"
}
      

Non-custodial standing and the consent we work under

Ballet positions the product as never holding user keys or funds; the app's own description states it does not retain private keys or store personal or financial data off the device. Under FinCEN's 2019 interpretive guidance, software that only helps a user control their own keys is not money transmission, and the EU's MiCA framework directs CASP licensing at custodians, exchanges and issuers rather than self-custody key-management software, per current EU regulatory summaries. Google Play has, since 2025, required some wallet listings to surface licensing in certain jurisdictions; that is a store-listing matter for the app, not a constraint on a read-side integration. Our footing is narrow and explicit. The card owner consents to sharing public addresses, we never request or reconstruct the BIP38-encrypted key or the passphrase, access is logged and data-minimized, and an NDA is in place where the client wants one.

What we account for on this wallet

These are things the studio handles in the build, not hurdles put on the client:

• We mirror the per-card activation list so the tracked address set matches exactly which coins a holder turned on, keeping activated-but-empty addresses distinct from unactivated ones.
• We map the address model so the classic single-deposit-address-per-asset card and the EVM reuse of one secp256k1 address across Ethereum, Polygon and BNB Chain resolve correctly without double-counting a balance.
• We pin the same spot-price source and rounding the app uses for its real-time market value, so the portfolio total reconciles with the in-app figure instead of drifting.
• When Ballet ships a new app version, a monitor compares its price and activation calls against the recorded ones, so a moved endpoint is flagged before any portfolio number goes wrong.
• Signing stays on the device after BIP38 decryption; our scope stops at reading, and the build runs against owner-provided public addresses or a test card, arranged with the client during onboarding.

Screens this mapping worked from

The app's public store screenshots, used to read the surfaced data domains. Select to enlarge.

What was checked, and where it came from

This mapping was put together on 2026-05-18 from the app's store listing, Ballet's own product and security documentation, the supported-asset references, and current EU and US regulatory summaries on self-custody software. The screenshots and the no-account, scan-to-start, real-time-value and multicurrency-activation behaviour were read from the listing; the BIP38 encryption, the two-factor private-key and two-factor key-generation model, and the on-device signing boundary from Ballet's security write-up.

• Ballet Crypto on Google Play
• Ballet — the companion app
• Ballet's security model: BIP38, 2FPK, 2FKG
• EU crypto regulation (MiCA) overview

Mapping by the OpenBanking Studio integration desk, 2026-05-18.

Other wallets an integrator runs into

Same category, named here for keyword context and because a unified integration usually spans several of them. Neutral, no ranking.

• Trust Wallet — multichain self-custody app whose balances and history live on the same public chains, queryable from the wallet's addresses.
• MetaMask — EVM-focused wallet; account data is on-chain per address, with an RPC and transaction layer an integrator reconstructs the same way.
• Exodus — desktop and mobile self-custody wallet across roughly 300 assets, holding portfolio state derived from public-chain addresses.
• Coinbase Wallet — self-custodial companion to the Coinbase exchange; its holdings are on-chain and independent of the exchange account.
• Tangem — card-based hardware wallet with a companion app, structurally close to Ballet in that the asset record is on-chain by address.
• Zengo — keyless MPC mobile wallet; balances and history still resolve from public-chain addresses for read integration.
• SafePal — air-gapped hardware wallet paired with an app, signing by QR while the holdings record stays on public ledgers.
• Ledger Live — companion app for Ledger devices spanning many chains, with per-account on-chain balances and transaction lists.
• Atomic Wallet — multi-asset self-custody wallet whose portfolio and history derive from addresses on the underlying chains.

Questions integrators ask about Ballet Crypto

If Ballet Crypto has no account, what is there to integrate?

The holdings record is not behind a Ballet sign-in. It is the permanent on-chain history of each card's deposit address, plus the price and activation layer the app uses to show a real-time portfolio total. We index the chains for the addresses the card owner shares and rebuild the same picture the app draws.

Do you ever need the card passphrase or the BIP38 key?

No. The card decrypts its private key on-device only to sign a send. Our work is read-side: balances, transaction history and valuation from public addresses. We do not request, transmit, store or reconstruct the encrypted private key or the passphrase, and the build runs against owner-provided addresses or a test card.

How do you handle a holder with several cards and many activated coins?

We mirror the per-card activation list so the address set tracked matches exactly which coins the holder turned on. Multiple Ballet cards roll into one portfolio object, and activated-but-empty addresses are kept distinct from unactivated ones so balances are not double-counted across EVM chains.

Will the portfolio total match the figure shown inside the app?

That is an explicit goal of the build. We pin the same spot-price source and rounding behaviour the app uses for its real-time market value, so the figure our endpoint returns reconciles with what a holder sees in Ballet Crypto rather than drifting by a few percent.

Getting a build started

A Ballet integration ships in one to two weeks: the indexer adapters, the valuation join, the OpenAPI specification, automated tests and the data-flow report. Source-code delivery starts at $300 and is paid only after delivery, once the code runs against your card addresses and you are satisfied with it. The alternative is the same capability as a pay-per-call hosted API with no upfront fee, where you pay only for the calls you make. Send the app name and what you need from its data through /contact.html, and access, test cards and any compliance paperwork are arranged with you as part of the engagement.