Protocol analysis, multi-chain balance & DeFi position exports, and transaction-history APIs for Rabby Wallet — the open-source EVM wallet by DeBank.
Rabby Wallet is a non-custodial EVM wallet backed by DeBank with support for 240+ chains, transaction pre-signing simulation, and a rich DeFi discovery layer. We help teams integrate, export, and normalize the wallet-side data that Rabby users generate every day — across the browser extension and the native Android / iOS apps.
Unlike centralized fintech apps, a wallet like Rabby holds no classic bank statement — but it holds something equally valuable: a verifiable, time-stamped record of every on-chain interaction a user has signed. Each approval, swap, bridge, lending deposit, or perpetual trade through Rabby leaves a trail that teams building OpenFinance for Web3 want to read, normalize, and reconcile.
In 2024 Rabby introduced a 0.25% swap fee alongside deeper integrations for chains such as IOTA EVM, and in 2025 it shipped native Hyperliquid balance tracking, lending-protocol integration with Aave, Spark and Venus, and per-DApp address selection controls. Each of these features generates new structured data points that your backend can subscribe to — not just "wallet A holds 1.2 ETH", but "wallet A has a variable-rate debt position on Aave v3 with an active health factor". Our role is to help you pull that data out through a clean, compliant API surface.
This page describes how we analyze Rabby's public @rabby-wallet/rabby-api surface, its injected EVM provider, and the underlying DeBank OpenAPI to ship production-grade integrations — with source-code delivery from $300 or a pay-per-call hosted endpoint.
Pulls total USD value, per-chain token balances, staked assets, and LP positions for any EVM address the user has connected in Rabby. Powers treasury dashboards, fund-of-funds reporting, and client-facing net-worth screens. Under the hood we use getTotalBalance, getTokenList, and per-chain protocol calls, then normalize symbols, decimals, and price oracles.
Exports swap, bridge, transfer, and contract-call history with timestamps, gas in wei and fiat, counterparty addresses, protocol names (Uniswap, Aave, 1inch, etc.), and categorized tags. Supports date range, chain filter, and pagination. Use case: generating tax-ready statements or feeding a general-ledger system.
Fetches open lending, borrowing, staking, and LP positions per protocol, including claimable rewards, health factors, and liquidation thresholds. Specific use: a risk desk that needs per-wallet borrow exposure on Aave / Spark / Venus refreshed every 60 seconds.
Enumerates outstanding ERC-20 and ERC-721 approvals (including unlimited-allowance flags) per connected wallet, plus Rabby's DApp connection list. Specific use: compliance alerts when a user has granted unlimited allowance to an unknown contract.
Captures the result of Rabby's pre-transaction simulation (expected balance change, risk labels, target contract) and forwards it to your backend for logging, co-signing, or policy enforcement. Specific use: corporate wallets that require a second approver before any call with a negative simulated balance change.
Push deltas (new transaction confirmed, new token detected, position liquidated, approval revoked) to your HTTPS webhook in near real time. Specific use: customer-facing notification services or automated rebalancing bots that must not rely on polling.
The table below lists the structured data we typically expose from a Rabby Wallet integration. Granularity and refresh frequency depend on the target chain's indexer and DeBank OpenAPI rate limits, but every row below has been delivered in production engagements.
| Data type | Source (screen / feature) | Granularity | Typical use |
|---|---|---|---|
| Address-level token balances | Home > Portfolio tab | Per-address, per-chain, per-token; updated every 30–60s | Net-worth dashboards, treasury reporting |
| DeFi protocol positions | Portfolio > DeFi section (Aave, Spark, Venus, Uniswap, Pendle) | Per-position (supply, borrow, LP, farm), with APR and rewards | Risk control, yield analytics, health-factor alerts |
| NFT & collectible holdings | NFTs tab | Per-collection, per-token ID, with floor price | Valuation, portfolio reporting, tax cost-basis |
| Historical transactions | History tab | Per-tx: hash, block, timestamp, gas, counterparty, protocol tag | Accounting, AML/KYT monitoring, statement export |
| Token approvals & DApp connections | Settings > Approvals / Connected sites | Per-contract, per-spender, per-token; allowance in wei | Compliance & security audits, auto-revoke flows |
| Swap / bridge route telemetry | Swap & Bridge modules | Per-quote: route hops, fees, slippage, source/destination chain | Best-execution analysis, TCA for Web3 trading desks |
| Transaction simulation results | Pre-sign popup | Per-request: expected delta, risk label, contract method | Policy engines, corporate co-sign, fraud checks |
Business context: an accounting SaaS needs to import a fund's full on-chain activity across 20 EVM addresses. Data & API involved: Rabby transaction history module + DeFi position module, normalized into double-entry records with cost basis in USD. OpenData / OpenFinance mapping: the same role that an Open Banking "Account Information Service" plays for a bank account, but applied to a non-custodial EVM wallet — the user authorizes the provider to read structured wallet data for accounting purposes.
Business context: a DAO council wants a single dashboard showing all multisig and Rabby-held assets, including locked staking and LP positions. Data & API involved: portfolio aggregation API + DeFi position module, refreshed every minute; optional webhook for >5% drawdowns. Mapping: an OpenFinance-style "wealth consolidation" feed, spanning on-chain instruments that don't exist in traditional PSD2 scopes.
Business context: an OTC desk onboards a counterparty that uses Rabby; the desk must run continuous Travel Rule, sanctions, and approval-risk checks. Data & API involved: transaction history + approval auditor + signature-intent relay, pushed into the desk's AML engine. Mapping: equivalent to account transaction monitoring under PSD2/AML6, but bridged to Web3 data.
Business context: a crypto-native company issues Rabby wallets to 30 employees and requires a second-approver policy on any transaction > $10k. Data & API involved: signature-intent relay module with simulation payload; integration with an internal approval service. Mapping: OpenBanking-style "Payment Initiation" flow, adapted for on-chain signing rather than SEPA/UPI rails.
Business context: a consumer app aggregates balances from Rabby, a centralized exchange account, and a bank account. Data & API involved: portfolio aggregation API from Rabby, CEX read-only keys, and an Open Banking AIS provider; merged server-side into a single timeline. Mapping: a classic OpenFinance use case extended with Web3 data — the integration layer we build for Rabby becomes the Web3 counterpart of a bank-data API.
Below are abbreviated samples from real integration kits. All code snippets are illustrative pseudocode and do not leak any private key material. Final deliverables ship with full source (Python / Node.js / Go), unit tests, and OpenAPI specs.
// Node.js, using @rabby-wallet/rabby-api
import { OpenApiService } from '@rabby-wallet/rabby-api';
const rabby = new OpenApiService({
store: { host: 'https://api.rabby.io' }
});
await rabby.init();
const address = '0xAbC...1234';
const total = await rabby.getTotalBalance(address);
const tokens = await rabby.getTokenList(address, 'eth');
// Response (trimmed):
// {
// "total_usd_value": 18432.55,
// "chain_list": [
// { "id":"eth", "usd_value": 12330.10 },
// { "id":"arb", "usd_value": 4102.20 }
// ]
// }
POST /api/v1/rabby/history
Content-Type: application/json
Authorization: Bearer <ACCESS_TOKEN>
{
"address": "0xAbC...1234",
"chains": ["eth","arb","base","op","bnb"],
"from_date": "2025-01-01",
"to_date": "2025-06-30",
"types": ["transfer","swap","bridge","approve"]
}
// 200 OK
{
"cursor": "eyJ0IjoxNz...",
"items": [
{
"tx_hash": "0x…",
"chain": "eth",
"block": 19842011,
"ts": "2025-02-14T08:21:03Z",
"type": "swap",
"protocol":"uniswap_v3",
"in": { "symbol":"USDC", "amount":"2000" },
"out": { "symbol":"ETH", "amount":"0.62" },
"gas_usd": 1.42,
"risk_label": null
}
]
}
// Webhook pushed to your backend before user signs
POST https://your-backend.example.com/rabby/pre-sign
X-Signature: t=1735689600,v1=5b0c…
{
"event": "pre_sign_simulation",
"wallet": "0xAbC...1234",
"chain_id": 1,
"method": "approve",
"target": "0x00000000219ab540356cBB839Cbe05303d7705Fa",
"simulation": {
"expected_balance_changes": [],
"allowance_changes": [
{ "token":"USDT","spender":"0xUnknown","amount":"unlimited" }
],
"risk_label": "unlimited_allowance_to_unverified"
},
"policy_hint": "require_second_approver"
}
// 200 -> allow; 403 -> block & prompt second signer
We always operate under explicit user or enterprise authorization and rely on publicly documented interfaces. For Rabby Wallet integrations specifically, we align deliverables with the regulations most frequently raised by our clients:
Rabby Wallet itself is non-custodial — private keys never leave the device. Our integrations preserve that property: we never handle seed phrases, and we strongly discourage any design that would require them.
A typical Rabby Wallet OpenData pipeline has four stages: (1) Client — the Rabby extension or mobile app, producing user-authorized reads and pre-sign simulation events. (2) Ingestion layer — our hosted API + webhook endpoints that call api.rabby.io, the DeBank OpenAPI, and chain RPCs, then normalize results. (3) Storage & enrichment — a time-series store (Postgres / ClickHouse) plus address metadata, protocol tags, and price oracle snapshots. (4) Consumer APIs — REST and webhook endpoints that your dashboard, accounting stack, or risk engine consumes. Every hop is logged with request IDs for audit.
Rabby Wallet is positioned as a "DeFi-native" alternative to generic browser wallets, favored by active Web3 users, DAOs, and small crypto funds. It is available as a Chrome/Brave/Edge extension and as a native Android & iOS app, with global distribution — historically with strong user clusters in North America, Western Europe, and East/Southeast Asia. Typical Rabby users are higher-signal on-chain participants: they interact with DeFi protocols, hold assets across multiple chains, and care about transaction simulation before signing. That profile makes Rabby data especially relevant for B2B tools (portfolio analytics, tax, treasury, compliance) rather than purely retail onboarding.
Representative screens from Rabby Wallet — click any thumbnail to open a larger view. These images are used purely for illustration; all trademarks belong to their respective owners.
Rabby Wallet sits in a broader ecosystem of Web3 wallets. Many of our clients maintain integrations across several of these apps at once and need a unified data model. The list below is not a ranking — these apps are simply part of the same integration landscape, and projects that combine Rabby data with any of them typically benefit from the same OpenData pipeline described above.
Source code delivery from $300: we hand over the runnable API source code and full documentation; you pay after delivery upon satisfaction.
Pay-per-call API billing: access our hosted endpoints directly and pay only for the calls you make — no upfront fee, ideal for teams that want to validate a use case before committing engineering time.
We are an independent technical services studio focused on App interface integration and authorized API integration. Our team combines hands-on experience in mobile engineering, fintech, and Web3 infrastructure — including protocol analysis, reverse engineering (for authorized research), OpenBanking / OpenFinance connectors, and high-throughput data pipelines. We ship end-to-end: from analyzing a target app's authorization flow to delivering tested, documented source code that your own engineers can maintain.
For Web3 wallets like Rabby, we pay particular attention to three things that distinguish a production-grade integration from a weekend script: correct handling of reorgs and pending transactions; normalization across heterogeneous chain indexers; and explicit, loggable user-authorization flows that satisfy compliance reviewers. Every project ships with a written compliance note tailored to your jurisdiction.
We work with clients globally — crypto exchanges, DeFi protocols, fintech builders, accounting SaaS, and in-house data teams — and we are happy to sign NDAs where required.
Ready to scope a Rabby Wallet integration or a broader OpenData project across Web3 and OpenBanking sources? Send us the target app, the data you need, and your target jurisdictions — we'll come back with a fixed quote (from $300) or a pay-per-call plan.
What do you need from us to start?
Do you ever touch private keys or seed phrases?
How do you handle compliance?
What if Rabby's API rate limits are too low for our volume?
api.rabby.io, DeBank OpenAPI, and direct chain RPC / indexer providers (e.g. custom nodes) so your effective throughput is not capped by a single source.Rabby Wallet - Crypto & EVM (package com.debank.rabbymobile) is the mobile companion to the popular Rabby browser-extension wallet, developed by the team behind DeBank. It is positioned as the "go-to wallet for Ethereum and EVM" and focuses on three things: tracking a user's portfolio across every EVM chain in one place, surfacing popular Dapps, and connecting to them seamlessly.
Rabby Wallet is an open-source, non-custodial wallet — private keys remain on the user's device. Integrations described on this page always assume explicit user or enterprise authorization and documented public interfaces.