CoinGecko’s Onchain Wallet endpoints give developers the ability to track profit or loss, token transfers, trades, and balances for a single wallet address. Together, these four data sets offer a comprehensive look at holdings, trading performance, and transaction activity across supported networks.
Developers can also merge trades and transfers into a time-sorted wallet activity feed while keeping profit and loss data separate. These tools are built for portfolio dashboards, wallet analytics services, and tax applications that require more than just a current balance.
While a wallet balance reveals what an address currently holds, trade and transfer logs show how those holdings evolved. CoinGecko notes that users need an API key on its Analyst plan or higher to utilize all four endpoints included in this workflow.
Wallet Balances Provide a Multichain Portfolio View
The Token Balances by Wallet Address endpoint fetches assets held by a single wallet across one or multiple networks. Developers have the option to specify several networks using a comma-separated list.
For instance, Arbitrum, Base, and Ethereum can all be included in a single request.
This layout eliminates the requirement to query individual blockchain RPCs separately and manually merge the results. Each holding comes with value_usd and price_usd, allowing applications to compute portfolio values without relying on an external price source.
Additionally, the endpoint features filters to enhance the quality of the returned holdings. Developers can apply token_type to separate native assets from non-native tokens, such as SPL or ERC-20 assets.
Meanwhile, reserve_in_usd_min and value_usd_min help filter out low-liquidity spam tokens and low-value holdings. The response also features a networks array detailing the holding count and USD value for each respective blockchain.
For the sample wallet, a balance query spanning Ethereum, Base, and Arbitrum yields a single data object. This allows applications to inspect the wallet’s chain distribution prior to diving into specific tokens.
Trades and Transfers Create a Chronological Activity Feed
CoinGecko’s Trades by Wallet Address endpoint pulls swap history for a wallet across a designated blockchain. It supports more than 250 networks, including Solana and Ethereum.
Every trade includes a kind field that identifies the transaction as either a buy or a sell. The response also supplies volume_in_usd, price_to_in_usd, and price_from_in_usd.
Consequently, trade values are pulled straight from the response payload. This removes the need for a separate historical pricing feed to compute the USD value of those swaps. Users can target a fixed window of up to 30 days by specifying both to and from parameters. Omitting these parameters causes the endpoint to return the previous seven days by default.
For more extensive histories, applications can leverage the next_cursor value found in the response metadata to paginate through additional results. The Token Transfers by Wallet Address endpoint captures asset movements that a trade-only history would otherwise leave out. This includes deposits, sends, airdrops, and other token movements. Every transfer features a token amount and a direction.
An in direction denotes that the wallet is the receiving address, whereas out signifies it is the sending address. CoinGecko’s workflow retains both records and categorizes each activity by its type. As a result, a single swap may generate two transfer records and one trade record representing the shifting assets.
Developers can execute the trade and transfer functions independently for each blockchain, then combine all outputs and sort them by timestamp to build a unified multichain wallet activity feed.
Read More: How Bitcoin Payment APIs Work, Where Businesses Can Use Them
Wallet PnL Adds Trading Performance Across Networks
The PnL by Wallet Address endpoint introduces another dimension by providing unrealized and realized profit and loss. Unlike isolated transactions, these figures represent aggregated performance metrics.
When the target chains belong to the same virtual machine family, the endpoint accommodates multiple networks in a single request. Arbitrum, Base, and Ethereum can thus be queried together because they operate on the EVM framework.
Because Solana belongs to a different environment, it demands a separate request. Its trading history can still leverage network=”solana” prior to the application requesting its PnL data independently.
The response contains total_unrealized_pnl_usd and total_realized_pnl_usd across the queried networks.
A networks array then breaks down the performance on a per-blockchain basis. Furthermore, CoinGecko supplies a token_stats array to deliver token-level PnL metrics, enabling applications to showcase overall performance alongside asset-specific and chain-specific results.
Because they serve different functions, PnL data remains distinct from the chronological activity feed. While trades and transfers reflect timestamped events, unrealized and realized PnL represent calculated sums.
Executing the outlined activity_feed.py workflow outputs the wallet’s PnL summary, portfolio value, and merged activity feed, alongside the performance breakdown per network.
Final Thoughts
CoinGecko’s collection of four wallet endpoints unifies trades, portfolio balances, transfers, and PnL into a single workflow. Developers are equipped to monitor multichain holdings and assemble timestamped activities while keeping performance figures separate. This architecture delivers the essential data foundation required for tax utilities, portfolio dashboards, and wallet analytics.
