Reaching Casper Wallet account data on the Casper Network

Casper Wallet keeps its signing keys on the handset; the balances, deploys and CEP-18 holdings it shows are read live from the Casper Network, not from a private server the app runs. That single fact decides the whole integration. There is nothing to log into on Casper's side — the account public key the wallet exposes is the join key, and everything a partner would want to sync (native CSPR balance, staking, token positions, transfer history, NFTs) sits in on-chain state that two well-documented surfaces already serve. The fast path is a real-time push: subscribe to balance events and fan them out as webhooks, then backfill the longer history behind that stream.

What sits behind a Casper Wallet account

Each row below is a real surface the wallet renders, mapped to where it actually originates and what an integrator does with it.

The ways in

Three routes genuinely apply here, plus a fallback. They are not equivalent, and we would not split work across all of them by default.

CSPR.cloud middleware — REST plus WebSocket

CSPR.cloud is an indexing and enrichment layer over the Casper Network. The REST side serves resource-oriented account, token and NFT endpoints; the streaming side is a WebSocket that emits balance and contract-level events as they land. It is the shortest path to production because the chain is already indexed and deploy history is queryable without you running an archival node. Access is token-based and tiered, which we set up with you during onboarding.

Direct Casper node JSON-RPC

A node on port 7777 answers query_balance, query_global_state and transaction lookups directly. No third-party in the loop and nothing to pay per call, but you carry the plumbing — indexing deploys yourself and keeping pace with the 2.0 transaction model. We use this as the resilience layer behind the index.

Authorized interface integration of the app itself

Some surfaces the wallet composes on the client — fiat on-ramp display, account import from the web extension. Where a partner needs to mirror exactly what the app shows, we analyze that read path under the customer's authorization and replicate it, framed as data extraction for interoperability rather than anything touching the user's keys.

Native export

The wallet's own public-key export and account import seed the join key cleanly; it is the simplest way to obtain the address that the other routes then resolve.

For most engagements the CSPR.cloud index is the right spine — it gives the real-time stream and the enriched history in one place — with the raw node kept underneath so a provider outage degrades to direct reads instead of a dark pipeline.

What ships to you

The deliverable is running code against your chosen account set, not a slide deck. In priority order:

• Runnable Python and Node.js clients for query_balance, account deploys, CEP-18 balances and NFT ownership, returning a normalized account view.
• A WebSocket consumer plus a webhook fan-out service that re-emits CSPR.cloud balance events to your endpoint, signed and retry-safe.
• A batch backfill script that walks deploy/transfer history with cursor pagination so a new subscriber starts with full context.
• An automated test harness pointed at testnet, asserting the mote-to-CSPR conversion and the liquid/staked/undelegating split stay correct across releases.
• A normalized schema (motes decimalized, asset classes unified) so CSPR, CEP-18 and NFT rows share one shape.
• Secondary artifacts: an OpenAPI description of the normalized endpoints, a short auth-flow note covering CSPR.cloud access-token handling, and data-retention guidance for any address-to-identity linkage you keep.

Live feed, end to end

The push path in practice: subscribe to the account-balances stream, receive the upstream updated event, normalize, and forward. Field names below are from the CSPR.cloud streaming docs and were confirmed during the build.

// 1) Subscribe to balance updates for one or more consented accounts
GET wss://streaming.example/account-balances?account_hash=<HASH1,HASH2>
    Authorization: Bearer <cspr_cloud_access_token>

// 2) Upstream emits an `updated` event (AccountBalance entity)
{
  "action": "updated",
  "data": {
    "account_hash":        "1f0e...c2a7",   // 64-char identifier
    "liquid_balance":      "412500000000",  // uint64 motes
    "staked_balance":      "900000000000",
    "undelegating_balance":"0",
    "deploy_hash":         "9b3d...18ef",
    "timestamp":           "2026-06-01T09:14:22Z"
  }
}

// 3) Our edge normalizes motes -> CSPR and re-emits a webhook
POST https://your-app.example/hooks/casper-balance
{
  "account":   "1f0e...c2a7",
  "asset":     "CSPR",
  "liquid":    "412.5",
  "staked":    "900.0",
  "undelegating": "0.0",
  "source_deploy": "9b3d...18ef",
  "observed_at": "2026-06-01T09:14:22Z"
}
// CEP-18 movements arrive on a parallel contract-event stream and map to the same envelope.

Things we account for on this chain

Concrete points specific to Casper that shape how we build, all handled on our side:

• Keys never leave the device, so we touch no signing path at all — the pipeline is strictly read-only, and we resolve a supplied public key down to its account hash (blake2b) so a client passing either form lands on the right account.
• Casper 2.0 renamed the unit of work from "deploy" to "transaction" in the RPC. We carry both vocabularies in the backfill so history that straddles the 1.x/2.0 boundary stitches together cleanly rather than splitting at the rename.
• Balances are uint64 motes at 10⁹ per CSPR, and the chain reports liquid, staked and undelegating separately. We keep that split end to end instead of collapsing it to one figure, because staking flows matter for any accounting use.
• The streaming layer is access-tier rate-limited; we design the subscription set and the REST backfill cadence around your tier so the feed stays inside quota without dropping events. Tier setup is arranged with you during onboarding.

Consent and data handling

On-chain Casper state is public, so the data itself is freely queryable. What needs care is the link between a wallet address and a real person, which is where data-protection law (GDPR and equivalents, depending on where the holder is) applies. The dependable basis we build on is the holder's own consent to associate their account with your service — we record that consent, minimize what is stored beyond the public address, and keep an NDA in place where the engagement touches your user identifiers. No recovery phrase, private key or device secret is ever in scope; the integration reads chain state and nothing the wallet treats as custodial. Halborn's audit of the wallet, noted in its store listing, concerns the app's own key handling rather than the read paths we build, but it is worth knowing the app's security posture is third-party reviewed.

Pricing and how a build runs

A first integration lands in one to two weeks. Source-code delivery starts at $300: you receive the runnable clients, the webhook service, the backfill script and the tests, and you pay after delivery once it works against your accounts. If you would rather not host anything, the pay-per-call hosted API has no upfront fee — you call our normalized endpoints and pay only for what you use. Tell us the app and what you want out of its account data; access, tier setup and consent handling are arranged with you as part of the work. Start the conversation here.

Where this gets used

• An exchange crediting CSPR deposits the moment the balance stream reports an inbound transfer, instead of polling every account on a timer.
• A portfolio tracker unifying a user's CSPR, CEP-18 tokens and NFTs into one normalized account view from a single consented public key.
• A treasury tool reconciling staked versus liquid CSPR across several validator delegations for reporting.
• A tax or accounting product generating per-account transfer statements from backfilled deploy history.

App screens

Store screenshots, useful for matching displayed figures to the underlying chain fields. Tap to enlarge.

Similar wallets an aggregator would also pull

Same self-custody category, different chains and indexers — useful context for anyone building one ingestion layer across several wallets. Each holds account-scoped balances and transaction history that a unified integration would normalize the same way.

• MetaMask — Ethereum and EVM accounts; balances and transaction history read from EVM RPC nodes.
• Trust Wallet — multi-chain holdings across many networks, each with its own node or indexer behind the address.
• Ledger Live — companion to Ledger hardware keys; portfolio and history across the chains it tracks.
• Coinbase Wallet — self-custodial app independent of the exchange, covering thousands of assets.
• Kraken Wallet — mobile-first multi-chain wallet with on-chain balances and history per address.
• Rabby — EVM-focused wallet with detailed per-transaction previews tied to account state.
• Coin98 — multi-chain wallet that also supports CSPR among many networks.
• Bitget Wallet — multi-chain self-custody wallet with broad token coverage, CSPR included.

Questions integrators ask

Casper Wallet is self-custodial — so where does the data we would read actually live?

The signing keys stay on the handset; the wallet never uploads them. The balances, deploys, CEP-18 holdings and NFTs it displays are read live from the Casper Network. We treat the account public key as the join key, derive its account hash, and pull the state read-only from Casper JSON-RPC or the CSPR.cloud index, with the user consenting to share their address.

Can balance changes be pushed to us in real time rather than polled?

Yes. The CSPR.cloud account-balances WebSocket emits an updated event carrying account_hash, liquid_balance, staked_balance and undelegating_balance whenever an account moves. We terminate that socket on our side and re-emit a normalized webhook to your endpoint; deploy history is backfilled over REST so a late subscriber is not left with gaps.

Do you cover CEP-18 tokens and NFTs, or only the native CSPR balance?

Both. CEP-18 fungible token balances come from each token contract, and NFTs following the CEP-47, CEP-78 and CEP-95 standards are read by contract package and token identifier. The native CSPR balance, staking and undelegating amounts are returned alongside them so one account view carries every asset class.

If we hand you only an account public key, what can you return?

From a single public key we can return the liquid and staked CSPR balance, CEP-18 token holdings, the deploy and transfer history, and NFT ownership for that account. No private key or recovery phrase is involved, since all of that data is read from on-chain state rather than from the device.

How this was put together

Checked in late May 2026 against the wallet's store listings, the Casper Network developer documentation, and the CSPR.cloud REST and streaming references, cross-reading the JSON-RPC method names and the balance event payload before writing the snippet above. Primary sources:

• Casper informational JSON-RPC methods (query_balance, query_global_state)
• CSPR.cloud streaming API — account balance events
• CSPR.cloud REST API — account entity
• Casper Wallet official site

Prepared by OpenFinance Lab — protocol engineering, May 2026.