Dappradar API filters for historical dapp research

Dappradar supplied decentralized application (dapp) activity through an API that filtered results by application, blockchain, and reporting period. This supported custom research models and products that consumed the platform’s data. The original platform announced its wind-down in November 2025, so these capabilities describe its historical service. Application identifiers located records, while chain and range selectors narrowed the reported activity. Saved responses remain useful within their recorded coverage and time window, with their original metric definitions intact.

Dapp identifiers, data endpoints, and query selectors

The Dappradar API supplied application records and NFT collection data. Application identifiers selected a dapp, endpoints selected the data family, and query parameters specified the reporting scope. The historical API used GET requests to retrieve information. These components supported software that combined activity measurements with application information for research or discovery.

Static application information and activity measurements also had different roles. Descriptions and category labels helped organize records, while transaction counts and volume supplied measured inputs. A model needed to preserve that distinction when joining data. Rankings organized activity data into ordered results, while API consumers could incorporate selected fields into their own models.

Application, chain, and reporting-window parameters

Chain and range selectors identified the network and measurement period of a dapp request. Their combination defined the activity that a returned metric described.

Application, chain, and reporting-window parameters

Chain and range selectors identified the network and measurement period of a dapp request. Their combination defined the activity that a returned metric described.

• Value supplied (Parameter) dappID: The requested application’s identifier chain: A supported blockchain name range: A supported reporting interval
• Data scope (Parameter) dappID: Application-specific path parameter chain: Query selector for blockchain activity range: Query selector for the measurement period

Each endpoint’s accepted values determined which blockchain names and intervals a request could select. These parameters supplied context for the returned metrics; they did not create missing coverage. Changing the chain or reporting interval changed the question that a response answered, even when the application identifier stayed the same.

View image file

Each endpoint’s accepted values determined which blockchain names and intervals a request could select. These parameters supplied context for the returned metrics; they did not create missing coverage. Changing the chain or reporting interval changed the question that a response answered, even when the application identifier stayed the same.

How did API data feed a custom research model?

API data supplied activity measurements and market information as inputs to a separately defined research model. The platform supported this use across dapp research and product integrations. The model’s assumptions determined how those observations became comparisons, indicators, or explanations.

A research question determined which fields belonged together. Transaction count described recorded transactions, while transaction volume represented value movement. Their relationship could help characterize activity. Neither field alone established why that activity occurred, so conclusions needed to remain within the meaning of the selected measurements.

Chain filters gave a model a defined network context. Category information could then organize applications with related functions. Comparisons still depended on the contracts that each record covered: identical filters did not make the underlying applications or tracking coverage identical.

Comparisons needed matching reporting windows. A wider window captured activity over a longer period, so mixing intervals could produce an apparent difference that came from measurement scope. That difference did not by itself demonstrate a change in the application’s underlying activity.

An activity increase supplied evidence of measured contract use. Predicting token demand required a separate relationship between that use and the token’s economics.

Activity measures and unit boundaries

Unique Active Wallets (UAW) measured distinct wallets interacting with a dapp within the selected scope. Transaction counts described recorded transactions. The platform’s general volume metric measured the value of token transfers into and out of tracked dapp contracts. These fields supplied different inputs, and an individual endpoint’s field definitions determined how a model could use them.

Units mattered when combining monetary fields. A token-denominated value and a monetary conversion needed their own unit labels. Any calculation involving prices also needed the corresponding valuation time. Without those details, an apparent increase could reflect a different unit or price basis. The same principle applied when placing application activity alongside token-market data.

Historical series and saved observations

Historical token-price data and activity totals answered different research questions, even when both concerned the same period. A price series described changes in a market value. An activity total summarized measurements within an interval. The requested range alone did not establish that every returned field had the same time resolution.

View image file

Saved responses should retain their request context and capture date. The original record preserves what a model actually consumed. A later copy with altered units or missing filters cannot explain the earlier result fully. A frozen response also cannot supply observations beyond its recorded coverage, however recently someone downloaded the file.

API credentials and request allowances

An API key authenticated access, while the chosen package determined the request allowance available to the application. Keeping that credential in private configuration protected the access attached to it. Publicly embedding a key could expose that access to others. Request allowances counted API use; they did not describe the number of wallets or blockchain transactions in a returned dataset.

Subscription packages and per-call billing

The historical service offered subscription packages and an on-demand option, creating different cost structures for recurring access and individual calls. The Trader plan described in the May 24, 2023 announcement included 2,500 calls per month for $9.99.

Subscription planning concerned the calls that an integration needed within its allowance period. Per-call billing tied cost to chargeable requests. Dataset access also mattered: an allowance did not by itself establish access to every data family.

NFT estimates, sale records, and token prices

NFT collection metrics, individual sale records, and estimated asset values supplied different kinds of information to API consumers. Collection data included trading volume and trader counts, while sale records concerned recorded trades. Machine-learning estimates supplied valuation outputs. By May 2023, the API included NFT price estimates as well as historical token data. An estimated value did not establish a completed sale at that amount. A model needed to preserve whether an amount represented an observed trade or a computed estimate before using it as a valuation input.

Token-market fields likewise needed their own interpretation. Price, market capitalization, and trading volume described market measurements. Dapp transaction volume concerned activity associated with tracked application contracts. A model could use both families, provided it retained their separate definitions. Calling each field simply volume would conceal the difference between market trading and application activity.

Direct API requests and MCP access

The Model Context Protocol (MCP) server introduced in July 2025 gave AI agents another interface to data from the API. It used an API key and exposed dapp, NFT, token, and DeFi information. Direct requests let an integration specify its query explicitly. MCP access supported requests through an AI client. Both approaches depended on the underlying data service and its coverage; changing the interface did not change what the measurements meant.

View image file

How did the shutdown change API-based research?

Dappradar announced in November 2025 that its wind-down would stop blockchain and dapp tracking. That change affected research that depended on continuing observations from the original service. A saved response remains an observation of its original period, and a functioning analysis of that file does not establish a continuing live feed.

Archived inputs can still support reproducible historical comparisons when their filters, units, and measurement windows remain intact. Extending those comparisons requires data for the additional period. A model that stops receiving observations must retain its final coverage date, so its outputs do not present old activity as a description of the current market.