A Phantom integration starts on-chain, not on a server

Phantom in one panel

Here is the bottom line. Because the wallet is a renderer of on-chain state, the dependable way in is to get a user’s consent to share their public addresses, then rebuild balances, tokens, NFTs, staking and history straight from each chain. Done that way the numbers match the wallet down to the lamport, and the integration keeps working when Phantom reshuffles its own screens. The connection protocol gets you the addresses; the chains give you everything else.

What a connected wallet exposes

These are the surfaces a Phantom user actually sees, mapped to where each one originates and what an integrator does with it. Granularity below reflects on-chain reality, not a guess.

Getting to the balances and history

Two methods carry the work, with a thin third for one-off pulls.

Address-keyed on-chain reconstruction

Given a user’s consented public addresses, rebuild the whole view from chain. On Solana that is getBalance for SOL, getTokenAccountsByOwner for SPL holdings, and getSignaturesForAddress (or a decoded variant such as Helius’ getTransactionsForAddress) for history. On the EVM chains it is JSON-RPC plus an EVM indexer; on Bitcoin, an Esplora-style indexer. Reachable: everything the wallet shows, since it draws from the same state. Effort is moderate — many chains, many token standards. Durability is high, because chain RPC and decoders do not move the way an app front end does. We stand up the keyed RPC endpoints, the decoders and the normalization layer.

The wallet’s connection protocol

Phantom exposes a documented connect-and-sign protocol — encrypted universal links on mobile and the injected window.solana / window.phantom provider on desktop. Analyzed for interoperability under the user’s in-wallet consent, it hands an integration the user’s public addresses and the ability to prompt a signature. On its own it is not a history feed; it is what bootstraps the reconstruction above. Effort is low to moderate, durability high — the payloads are encrypted and the handshake is documented. We implement the handshake and manage the encrypted session.

Address-based export

For a single snapshot where nobody wants a live connection, a public-address CSV pulled from an explorer or indexer covers it — the same path tax importers use to read a Phantom address. Light, and only worth it for one-time work.

In practice we pair the first two: the connection protocol gives us consented addresses, the on-chain reconstruction does the heavy lifting from there, and the CSV path stays parked unless a client only needs one dated pull. That pairing is what makes the figures reconcile against the wallet rather than approximate it.

What you receive at the end

Concrete artifacts, all tied to Phantom’s real surfaces:

• An OpenAPI/Swagger specification for the normalized endpoints — balances, NFTs, activity, staking — across whichever chains you scope.
• A protocol and auth-flow report covering the connect handshake, the encrypted universal-link payloads, and the provider-injection path, with the session and signature flow written out.
• Runnable source for the key calls in Python or Node.js: the per-chain RPC/indexer clients, the decoder that turns signatures into typed activity, and the normalizer.
• Automated tests, including fixtures that replay a known address so balances and history stay reproducible across runs.
• Interface documentation, plus guidance on data minimization and retention for the address and on-chain data you hold.

The calls behind a balance pull

A trimmed view of the Solana side of a reconstruction. Method names were confirmed against the Solana JSON-RPC during the build; treat the rest as illustrative.

# Reconstruct a Phantom user's Solana view from a consented public address.
import requests

RPC   = "https://api.mainnet-beta.solana.com"   # swap for a keyed indexer endpoint
OWNER = consented_address                        # from the connect handshake

def rpc(method, params):
    r = requests.post(RPC, json={
        "jsonrpc": "2.0", "id": 1, "method": method, "params": params
    }, timeout=15)
    r.raise_for_status()
    body = r.json()
    if "error" in body:                          # -32xxx: rate limit, bad params, node lag
        raise RuntimeError(body["error"])
    return body["result"]

lamports = rpc("getBalance", [OWNER])["value"]
sol      = lamports / 1_000_000_000              # lamports -> SOL

# SPL holdings: each token sits in its own associated account
TOKEN_PROGRAM = "TokenkegQfeZyiNwAJbNbGKPFXCWuBvf9Ss623VQ5DA"   # confirmed during build
tokens = rpc("getTokenAccountsByOwner",
    [OWNER, {"programId": TOKEN_PROGRAM}, {"encoding": "jsonParsed"}])["value"]

# Recent activity -> decode each signature into swap / stake / nft / transfer
sigs = rpc("getSignaturesForAddress", [OWNER, {"limit": 50}])
# the decoder step is where the Activity-tab labels come from
        

One schema across Solana, EVM and Bitcoin

A multi-chain wallet only reads as one thing if the records do. We collapse native units — lamports, wei, satoshis — and the SPL-versus-ERC-20 metadata differences into a single shape, with a per-chain adapter feeding it.

{
  "account": "consented-public-key",
  "chain": "solana",
  "positions": [
    { "asset": "SOL",  "kind": "native", "amount": "12.84", "decimals": 9 },
    { "asset": "USDC", "kind": "spl", "mint": "EPjF...Dt1v", "amount": "300.0", "decimals": 6 }
  ],
  "activity": [
    { "type": "swap",  "in": "SOL", "out": "USDC", "ts": 1730000000, "sig": "..." },
    { "type": "stake", "validator": "...", "amount": "5.0", "ts": 1729900000 }
  ]
}
        

The same record describes an Ethereum holding by switching chain to ethereum, kind to erc20 and decimals to 18 — the consumer of the feed never has to special-case a network.

Consent, keys, and the rules that touch crypto wallets

Phantom is non-custodial. The user holds the keys, and we never ask for them — a build works from public addresses the user agrees to share and from chain data that is public and pseudonymous. The dependable legal basis here is that consent, recorded per session, not a banking data-rights statute.

For EU users, GDPR governs any personal data the integration retains; the practical posture is to keep addresses and on-chain records only, drop anything you do not need, and log access. MiCA is the regulatory backdrop for crypto-assets — its crypto-asset-service-provider provisions came into force at the end of December 2024, per ESMA — but self-custodial wallets such as Phantom largely sit outside that licensing perimeter, so the access basis stays the user’s own consent rather than a scheme membership. We operate authorized, logged and data-minimized, under NDA where a client needs one.

What we plan around on a self-custody build

• Unit and metadata normalization. We map lamports, wei and satoshis to one decimal convention and reconcile SPL token metadata against ERC-20 fields, so a balance reads identically whether it came off Solana or an EVM chain — no chain leaks into the consumer’s logic.
• Decoded history, not raw signatures. Plain RPC returns signatures, not human-readable events. We wire in a decoder/indexer pass so swaps, stakes and NFT moves carry the labels the Activity tab uses, and we run a backfill harness to reach historical depth a single RPC call would never page through.
• Multiple accounts and token accounts. A Phantom user can run several accounts and many per-chain addresses, each SPL token in its own associated account; we enumerate every consented address and its token accounts so balances are not silently undercounted.
• Protocol drift. When the connect handshake or the provider interface shifts, we keep a small contract-test suite against it so a change surfaces in CI rather than in production. Access is arranged with you during onboarding, and the build runs against public mainnet data and a consenting test account.

Screens we worked from

The store screenshots used while mapping the surfaces above. Select one to enlarge.

How this mapping was put together

Checked in June 2026 against Phantom’s own help and developer documentation for the supported-network list and the connect protocol, Helius’ indexing docs for how decoded Solana history is pulled, and ESMA’s MiCA page for the crypto-asset regulatory status. Primary references:

• Phantom — supported blockchain networks
• Phantom developer docs — deeplinks (iOS and Android)
• Helius — how to index Solana data
• ESMA — Markets in Crypto-Assets Regulation (MiCA)

Mapped by the OpenBanking Studio integration desk — reviewed 2026-06-11.

Other wallets in the same picture

A unified integration usually has to read more than one wallet, so these come up alongside Phantom:

• MetaMask — EVM-first wallet holding token balances, NFTs and transaction history across Ethereum and its layer-2s.
• Solflare — Solana-native wallet with staking, swaps and portfolio data much like Phantom’s.
• Backpack — Solana and multi-chain wallet pairing balances and collectibles with an exchange account.
• Trust Wallet — broad multi-chain wallet covering balances and NFTs across many networks.
• Coinbase Wallet — self-custody wallet holding on-chain assets separate from the Coinbase exchange account.
• Rainbow — Ethereum wallet focused on tokens, NFTs and readable transaction history.
• Exodus — multi-chain wallet with portfolio, swap and staking records across dozens of assets.
• 1inch Wallet — non-custodial wallet built around a DEX aggregator, holding balances and swap history.
• OKX Wallet — multi-chain wallet spanning balances, NFTs and DeFi positions across many networks.

Questions integrators ask about Phantom

Do you need our users’ seed phrases or private keys?

No. A Phantom wallet is non-custodial, so the keys stay in the app and never reach us. We work from the public addresses a user agrees to share through the connect flow, plus the public on-chain state behind them.

Will the numbers match what a user sees in the Activity tab?

They line up, because the wallet itself is just rendering on-chain state. We rebuild balances and history from the same chains and run the records through a decoder so swaps, stakes and NFT transfers carry the labels the Activity tab uses. Anything still pending is marked rather than silently dropped.

Which chains can one integration cover?

Solana, Ethereum, Base, Polygon, Sui, Monad, Bitcoin and HyperEVM, which is the network set Phantom lists as supported. We normalize them into a single record shape and scope the build to whichever subset you actually need.

If Phantom adds another chain after we ship, what happens?

The normalization layer is built as per-chain adapters, so a new network is a new adapter rather than a rewrite. That kind of change fits inside the usual one-to-two-week cycle and is handled as maintenance.

Getting a Phantom build started

A reconstruction like this lands in one to two weeks. Source-code delivery starts at $300: you get the runnable per-chain connectors, the OpenAPI spec, the decoder, the tests and the docs, and you pay once it is in your hands and reconciling against real addresses. If you would rather not host anything, the same normalized endpoints run as a pay-per-call hosted API with nothing upfront — you pay only for the calls you make. Tell us the app and what you want out of its data at /contact.html, and we will scope the chains and the surfaces with you.