Reading Arculus Wallet balances, history and addresses without touching the Key Card

Every Arculus balance, transfer and staking reward already exists on a public blockchain — the Key Card only controls who can sign, not who can read. That single fact decides the whole integration. The portfolio a user sees in the app (holdings across many chains, per-asset receive addresses, an exportable transaction ledger, Cardano, Solana and Cosmos staking, NFTs, and swap orders routed through outside liquidity partners) is reconstructable from public chain data plus a thin layer of authorized work on the app's own pricing and partner calls. No keys leave the card's secure element, and a read-only sync never asks them to.

Bottom line: the spine of this job is on-chain. Once we have the owner's per-chain addresses or an xpub set, balances, transfers and staking events are readable directly and stay readable even if the app changes. The app-only pieces — the user's display-currency valuation and the OnRamper / Transak / Changelly order records — are a smaller, separate slice we capture under the owner's authorization. We would build on-chain first and treat the app traffic as enrichment, not as the foundation.

What the wallet holds, and where each piece really lives

Three authorized ways to reach this data

On-chain sync from the owner's public addresses

The durable one. Receive addresses (or an xpub set) make every balance, transfer and staking event readable from public chain data and indexers, with nothing depending on the app's internals. Third-party tax tools already ingest Arculus this way, which is a fair signal the route holds over time. Setup is light: we work with the owner to enumerate the per-chain addresses during onboarding, then the sync runs on its own.

Native export ingestion

The History tab produces a downloadable transaction file. We build a parser and normalizer for that export plus an upload or watched-folder pipeline, so a user who can tap a button can feed a clean ledger without any address handling at all. Effort is low; the only fragility is export-schema drift, which we account for below.

Authorized protocol analysis of the app's own calls

Some surfaces never hit a chain: the user's fiat valuation, the OnRamper / Transak / Changelly order records, the WalletConnect session list, NFT enrichment. For those we analyze the app's traffic to its pricing and partner backends under the owner's authorization and implement the relevant calls. We document the NFC/Key Card APDU layer as part of this — and document it as a boundary we deliberately stay on the read side of, never one we work around.

A fourth path, user-consented access on a consenting test device, is how we capture the protocol-analysis surfaces in practice. Our recommendation for almost every Arculus engagement: build the on-chain sync as the backbone, fold the export parser in for users who prefer it, and add the protocol layer only for the fiat and partner-order fields that genuinely need it.

What lands in your repo

• An OpenAPI/Swagger spec for the normalized surface — /balances, /history, /staking, /orders, /nfts — modelled on the seven domains above.
• A protocol & auth-flow report: the app-to-backend pricing and partner call chain, its token/cookie handling, and the NFC APDU boundary written up as documented-but-untouched (read paths need no card).
• Runnable Python and Node.js source: address-derived multi-chain sync, the History-export parser, and the partner-order fetch with reconciliation.
• A normalized ledger schema that collapses on-chain, export and partner views into one row per economic event.
• Automated tests against captured fixtures, interface documentation, and data-retention guidance scoped to non-custodial wallet data.

A look at the address-and-history call path

# Arculus unified-ledger build -- read paths only, no Key Card, no PIN
# 1. Addresses come from the owner (exported list or xpub set)
addrs = derive_addresses(xpubs, gap_limit=20)        # per-chain, incl. low-activity chains

ledger = []
for chain, addr in addrs:
    bal = indexer.balance(chain, addr)               # public chain data, app not involved
    for tx in indexer.transfers(chain, addr):
        ledger.append(normalize(tx, chain))

# 2. App-only surfaces captured via authorized protocol analysis
#    (display-currency valuation + buy/sell/swap orders)
r = session.get(PRICING_BASE + "/v?assets=" + ",".join(assets),
                 headers=auth_headers)               # token chain set out in the report
if r.status_code == 401:                             # session expired mid-sync
    auth_headers = refresh(auth_headers)
    r = session.get(PRICING_BASE + "/v?assets=" + ",".join(assets),
                     headers=auth_headers)           # retry once, then fail loud
fiat = r.json()["prices"]                            # owner's display currency

for o in partner_orders():                           # OnRamper / Transak / Changelly
    merge_or_dedup(ledger, o)                        # one swap -> one ledger row

write_openapi(ledger_schema)                         # /balances /history /staking /orders
      

The error branch is deliberate: the pricing call carries a session that expires, and a silent failure there would leave valuations stale while the chain data still looks fresh. We refresh once and fail loudly rather than serve a half-correct portfolio.

Self-custody changes the compliance picture

There is no account here for a vendor to grant a third party. Arculus is non-custodial: keys are generated and held in the card's secure element (Arculus describes the classification as CC EAL6+), the company states it cannot access keys or recover accounts, and there is no server-side balance ledger to authorize against. So the authorization that matters is the wallet owner's consent to read their own addresses and exports — which is exactly the surface our routes use. On-chain data is public by design; the export is the owner's own file.

Where personal data does enter the pipeline (display-currency settings, partner order records tied to identity), the governing frame is data-protection law rather than any open-banking regime — for US users that includes California's CCPA/CPRA — together with the wallet's own terms. KYC and money-transmission obligations on the buy/sell flow sit with the regulated liquidity partners, not the wallet. We run authorized and logged, minimize to addresses and ledger rather than anything key-bearing, and work under an NDA where the engagement calls for it.

Engineering realities we plan around

Two things decide whether an Arculus sync is correct rather than merely plausible, and we design for both from the start.

Address discovery is the whole game. The card derives many per-chain addresses from one seed; miss a funded address on a chain the owner rarely uses and the portfolio is quietly wrong. We run gap-limit scanning and xpub-based derivation wherever the app exposes it, so coverage does not depend on the user remembering which chains they touched.

A single swap appears three times. The same trade can show up in the History export, on-chain as a transfer, and as an OnRamper / Transak / Changelly order. We build the reconciliation that collapses those into one event so balances and cost basis are not double-counted.

Two more we handle as routine: display-currency valuations come from the app's pricing backend, not the chain, so we capture the owner's selected fiat and the pricing source to make figures match the screen; and the export schema and partner set can shift, so we keep a schema-diff check in the maintenance window that turns a format change into a failed test instead of a silent gap. Access to any consenting test device is arranged with you during onboarding — it is part of how the build runs, not something to clear beforehand.

Where teams actually put this

• A crypto-accounting product onboarding Arculus users who would rather not hand-upload CSVs every quarter — address-derived sync plus the export parser as a fallback.
• A family-office dashboard consolidating a cold-storage sleeve held on Arculus alongside custodial holdings, valued in the principal's home currency.
• A tax engine that needs swap cost basis correct to the cent, where the OnRamper/Transak/Changelly reconciliation is the hard part.
• An internal treasury tool tracking ADA/SOL/ATOM staking rewards as they accrue rather than at withdrawal.

Screens we mapped

The surfaces named in this brief were checked against the app's own store screenshots.

Other card-and-app and hardware wallets in the same space

Same category, useful when a unified integration has to span several cold wallets at once. Plain context, no ranking.

• CoolWallet — the closest in design: a physical card plus mobile app with WalletConnect, holding multi-chain balances, history and DeFi session data.
• Tangem — NFC smart-card wallet; per-card balances, addresses and transaction history on the mobile app.
• Ledger — USB/Bluetooth hardware wallet with Ledger Live holding broad multi-chain portfolio and transfer data.
• Trezor — hardware wallet whose Trezor Suite app exposes balances, addresses and exportable transaction history.
• SafePal — hardware and software wallet with portfolio, swap and on-chain activity records.
• D'CENT — biometric and card hardware wallets with multi-chain balance and transfer surfaces.
• Cypherock — seed-split hardware wallet holding multi-chain portfolio and transaction data via its app.
• Ellipal — air-gapped hardware wallet with a companion app exposing balances and transfer history.

How this brief was put together

Checked in May 2026 against the vendor's own documentation and an independent integration source: the Arculus product and FAQ pages for asset coverage and the History export, the WalletConnect capability announcement for supported networks, the CompoSecure product page for the non-custodial and secure-element claims, and a third-party tax tool's Arculus page confirming public-address and export ingestion are established. Specific identifiers and coverage figures here are attributed to those listings rather than asserted independently.

• Arculus FAQs — features, supported assets, export
• CompoSecure — NFT support and WalletConnect networks
• CompoSecure — Arculus non-custodial / secure element
• CoinLedger — Arculus import via export and public address

Mapped by the OpenBanking Studio integration desk · May 2026.

Questions integrators ask about Arculus

Do you need the Arculus Key Card or my PIN to pull the data?

No. The Key Card and PIN are a signing boundary, not a reading one. Balances, receive addresses and transfer history live on public blockchains and in the app's history export; none of those read paths need the physical card, the PIN or the biometric. We scope the build to read-only by design, so the card never enters the integration.

The wallet spans dozens of blockchains — which of my balances actually sync?

Anything derivable from the wallet's public addresses syncs straight from chain data and indexers, independent of the app. Cardano, Solana and Cosmos staking positions and ERC-721 / ERC-1155 NFTs are picked up by per-chain queries. We run gap-limit and xpub-based address discovery so funds on chains the owner rarely touches are not missed.

Why does this brief keep mentioning OnRamper, Transak and Changelly?

Arculus routes in-app buy, sell and swap through those liquidity partners, so order records (pair, rate, fee, partner) are a separate surface from the on-chain transfer. We fetch and reconcile them against the chain movement so a single swap becomes one ledger row instead of three.

Is on-chain data enough, or do I also need the app's export?

On-chain covers most of the ledger. The History-tab export and the app's pricing backend add the owner's display-currency valuation (USD, AUD, CAD, EUR or GBP) and the exact view the user sees. We combine both so reported figures match the app screen.

A runnable Arculus sync — address-derived multi-chain ledger, History-export parser, partner-order reconciliation, automated tests and the interface documentation — is built and handed over inside one to two weeks. Source-code delivery starts at $300, billed only after the work is delivered and you have confirmed it runs against your data; if you would rather not host it, the same endpoints are available as a pay-per-call API with nothing charged upfront. Give us the wallet name and what you need out of it, and the access and compliance details are worked out with you from there — start at our contact page.