Reading a Rainbow wallet across mainnet, Optimism, Base and Zora

Almost everything a Rainbow user sees starts from one Ethereum address and fans out across six networks. Balances, sends, swaps, bridges and NFT ownership for that address live on Ethereum mainnet, Optimism, Arbitrum, Polygon, Base and Zora — public, pseudonymous, and readable the moment you hold the address. The app then layers its own metadata on top: a published token list, decoded activity, ENS profile records, and a notifications stream. An integration that wants a faithful copy of what Rainbow shows has to read both halves and reconcile them. That reconciliation is the work.

Because Rainbow never custodies funds, there is no statement endpoint to query the way a bank app has one — the ledger is the chain. So the working route is straightforward to state: index the address across all six networks for the things the chain already records, and analyze the app's own traffic for the metadata it adds. We recommend running both together rather than either alone, because the chain gives you truth and Rainbow's surfaces give you the labels — symbols, decimals, swap categories, profile names — that make that truth legible.

What sits behind a Rainbow address

Routes into the data

1 — Address-keyed on-chain indexing

For balances, transfers, NFT ownership and the raw history, the address is all you need. We read each of the six networks through a JSON-RPC provider, scan logs for ERC-20 and ERC-721/1155 movements, and assemble a per-address portfolio. Reachable: nearly everything financial the wallet shows. Effort: moderate, mostly indexer plumbing. Durability: high — this is public chain state and does not change shape when the app updates. We set up the provider keys and the indexing layer as part of the build.

2 — Protocol analysis of Rainbow's backend surfaces

The labels Rainbow adds — its token list, decoded swap categories, ENS profile fields, price data and the notifications stream — come from its own services. We map that traffic under the holder's authorization and reproduce the calls the app makes, so the copy carries the same symbols and categories the user sees. Effort: higher, and it tracks app changes. Durability: medium — we re-validate when a surface shifts. This route is what keeps the on-chain numbers human-readable.

3 — User-consented address access

Where the project is monitoring a specific holder rather than public addresses at large, the holder names the addresses (or imports a watch-only view, exactly as Rainbow's own watch feature works), and that grant scopes the whole integration. We arrange this with the client during onboarding.

The combination we put forward for most Rainbow projects is route 1 carrying the financial truth and route 2 supplying the metadata that makes it readable; route 3 is how a single-holder engagement is scoped. Pick route 1 alone only when raw on-chain numbers without Rainbow's labels are genuinely enough.

The read flow, in outline

A single address resolves to a normalized multichain portfolio; Rainbow's token list then supplies the display metadata. Field and host names are confirmed against live traffic during the build.

# Illustrative — resolve a Rainbow-managed address to a normalized
# multichain portfolio. Endpoint and field names verified during the build.

CHAINS = ["ethereum", "optimism", "arbitrum", "polygon", "base", "zora"]

def portfolio(address):
    out = {"address": address, "chains": {}}
    for chain in CHAINS:
        native = rpc(chain, "eth_getBalance", [address, "latest"])
        tokens = index_erc20(chain, address)   # log scan via an indexer
        nfts   = index_erc721(chain, address)  # ERC-721 / ERC-1155 ownership
        out["chains"][chain] = {"native": native,
                                "tokens": dedupe(tokens),
                                "nfts": nfts}
    return out

# Rainbow's published token list supplies symbol / decimals / logo.
# Observed to refresh on a ~12h schedule via the project's GitHub action.
TOKEN_LIST = "https://metadata.p.rainbow.me/token-list/rainbow-token-list.json"

def label(token, token_list):
    meta = token_list.get(token["contract"].lower())
    if not meta:                      # unknown contract: flag, don't drop
        return {**token, "symbol": None, "needs_review": True}
    return {**token, "symbol": meta["symbol"], "decimals": meta["decimals"]}
      

The needs_review path matters: an address can hold tokens the published list has not caught up to, and silently dropping them would understate a portfolio. We flag instead.

What lands at the end

The output is built around the surfaces above, not a generic template:

• An OpenAPI / Swagger spec describing the normalized portfolio, activity, NFT and profile endpoints we expose for a Rainbow address.
• A protocol and auth-flow report covering the backend surfaces we analyzed — the token-list host, the notifications calls, ENS resolution and how each is authenticated.
• Runnable source for the core reads (Python or Node.js): multichain balance and history indexing, NFT ownership, ENS resolution, token-list labelling.
• Automated tests, including the dedupe-across-chains and unknown-contract cases.
• Interface documentation, plus data-retention and consent guidance scoped to addresses the holder names.

Consent and privacy posture

Rainbow holds nothing on the user's behalf — the app is explicit that you own your assets directly through the keys you control. That shapes the consent model. On-chain data is public and pseudonymous, and the address the holder controls is itself the basis for reading it; there is no banking-style account-information regime in play here because there is no account holding funds. For the EU, non-custodial software wallets of this kind sit largely outside the CASP licensing perimeter under MiCA, so the relevant frame for any account-linked surface — an ENS profile, a notifications subscription, a support contact — is data protection: GDPR and, for US users, CCPA. We operate authorized and logged, minimize stored data to the addresses a client names, keep consent records, and sign NDAs where a project needs one.

Engineering notes we account for

Two specifics shape how we build a Rainbow integration, and we handle both rather than passing them to the client:

• A token that exists on several of the six networks would be counted more than once by a naive sum. We deduplicate by contract-and-chain and reconcile bridged positions, so a portfolio total matches what the user actually holds.
• Rainbow decodes activity into categories — a swap reads differently from the raw transfer logs underneath it, and mainnet swaps route through Flashbots Protect, where the public mempool view differs from the user's. We map the app's decoded categories instead of re-deriving them naively, and we wire the token-list's roughly 12-hour refresh into the sync so symbol and decimal changes do not silently desync. When a backend surface changes shape, a re-validation pass against live traffic catches it.

Working with us

You hand over the app name and what you want out of a Rainbow address; we arrange the access and the provider setup from there. Source-code delivery starts at $300 — you receive runnable code with the OpenAPI spec, tests and documentation, and you pay after delivery, once it does what you asked. If you would rather not run anything, the hosted option exposes the same reads as endpoints you call and pay for per call, with nothing upfront. Either way the build runs on a one-to-two-week cycle. Tell us which surfaces you need and we will scope it — start a brief here.

Interface evidence

Screenshots from the app's store listing, for reference on the surfaces named above.

How this was checked

Compiled on 2026-06-07 from the app's own Play Store and App Store descriptions (chains, NFT formats, ENS, Flashbots Protect, watch-only addresses), the project's public GitHub repository, and its published token-list endpoint, which the repository's action refreshes on roughly a 12-hour schedule. Citations:

• github.com/rainbow-me/rainbow — the open-source app repository
• github.com/rainbow-me/rainbow-token-list — published token list and refresh cadence
• App Store listing — feature and chain claims
• learn.rainbow.me — self-custody, ENS and supported-network notes

Mapped by the OpenBanking Studio integration desk — June 2026.

Similar wallets an integrator might unify alongside it

Same category, all holders of address-keyed multichain data that a single integration could read together:

• MetaMask — widely used EVM wallet; balances, swaps and dApp sessions across many chains.
• Coinbase Wallet — self-custodial wallet covering tokens, NFTs and DeFi positions across networks.
• Trust Wallet — multi-chain wallet holding tokens, NFTs and staking activity.
• Rabby Wallet — EVM-focused wallet with detailed transaction simulation and multichain balances.
• Zerion — portfolio-first wallet aggregating positions and history across dozens of chains.
• Zengo — MPC-based self-custodial wallet holding tokens and recovery metadata.
• Frontier — multi-chain DeFi and NFT wallet spanning thousands of assets.
• OneKey — open-source wallet pairing hardware and software with multichain balances.
• Wigwam — browser-based multichain wallet for tokens and dApp access.

Questions integrators ask

Is on-chain reading enough, or do you also pull Rainbow's own backend surfaces?

Both. Balances, transfers and NFT ownership come straight off mainnet and the L2s keyed to the address. On top of that we map Rainbow's own surfaces — its published token list, the notifications endpoint and the ENS profile records — because they hold the symbol, decimal and identity metadata that raw chain logs do not carry.

Which chains does a single sync cover for a Rainbow address?

The wallet describes support for Ethereum mainnet plus Optimism, Arbitrum, Polygon, Base and Zora. We run the read across all of them per address and deduplicate a token that shows up on more than one network so a portfolio total is not inflated.

How do you handle NFTs and ENS names tied to a wallet?

NFTs are read as ERC-721 and ERC-1155 ownership with their media references — including the 3D, AR, video and POAP formats Rainbow renders. ENS names resolve through the registry, and the Rainbow profile backend adds the avatar, social handles and the rainbow.me username where the holder set one.

Does self-custody change what authorization you need?

It simplifies it. Rainbow holds no assets for the user, so the address the holder controls is itself the consent key for the public on-chain reads. For any account-linked surface we scope access with the holder during onboarding and keep records data-minimized to the addresses they name.