Covalent
Covalent App Workloads: Wallets, Markets and Analytics
Covalent's GoldRush APIs provide balance snapshots for dashboards, transaction records for accounting and live feeds for market monitoring. The trial and Vibe Coding plan list 4 requests per second (RPS) for Foundational REST. Scheduled balance queries, live market feeds and warehouse records serve different jobs, so a faster plan alone won't resolve every mismatch. Wallet dashboards need fresh holdings; activity analysis needs appropriate historical coverage; streaming requires support for the requested feed.
A dashboard's polling budget depends on upstream requests, while live streams supply events without replacing every balance or historical query.
Can REST polling keep a wallet dashboard current?
GoldRush REST polling fits a wallet dashboard when paced requests meet the plan's throughput limit and the application's freshness target. The token-balance endpoint returns native and fungible holdings for a selected wallet and chain, with spot prices and metadata. Those fields provide a holdings snapshot for a portfolio screen, and the application's next request supplies another response; repeatedly rendering an existing response doesn't issue another upstream call.
Request demand follows the wallets, chains and endpoints an application queries, together with their refresh intervals, although a shared cache can reduce repeated calls for identical queries. Separate views requiring different wallets, networks or query options won't necessarily share a relevant response. Page views therefore aren't a direct measure of API demand.
A reused response retains its original generation timestamp even when the screen displays it again.
Freshness also concerns the data returned by the endpoint. A request schedule describes how often an application asks for data, not how recently every underlying record changed. The app needs to distinguish its last fetch from the response's reported generation time and the latest signed block reported in that response. Throughput planning and freshness display answer different questions.
Transaction records for accounting and reconciliation
GoldRush transaction histories fit accounting jobs needing decoded events, historical prices and gas-usage summaries on applicable chains. Transaction records explain recorded activity over a period. Their pricing fields can support historical valuations, while gas fields describe transaction execution costs. An accounting view needs the appropriate records and valuation time; refreshing a current holdings response won't supply that transaction context.
Historical balance queries address holdings at an earlier point. Internal transactions and EVM historical token-balance enrichments require Foundational Chain support. Ethereum, Base and Polygon are in that category. The chosen chain's capabilities determine whether the job can use those enrichments. Ordinary transaction records remain useful for activity analysis, but they shouldn't silently substitute for a requested historical balance snapshot.
One prototype, two refresh requirements
A hypothetical prototype tracks 13 wallets on one supported chain and refreshes each wallet's balance every 7 seconds. The wallet count and interval are illustrative inputs. Assume the chain supports both the balance endpoint and the required price stream, with one balance call per wallet refresh. The question is whether holdings updates fit the trial's published 4 RPS budget while a chart receives live prices.
The balance workload averages 13 divided by 7, or approximately 1.86 requests per second, which leaves arithmetic headroom below the trial's 4 RPS limit before other REST traffic uses that capacity. Sending all 13 requests within one second would exceed the published rate. Spreading them across the refresh interval avoids that scheduled burst, although the average alone doesn't establish compliant pacing or response latency.
The price stream can update the chart independently of the balance job, while market-price events don't establish freshly queried wallet holdings across the prototype's tracked addresses. The prototype therefore uses REST for its periodic holdings responses and a supported stream for price updates, with each serving a different part of the display.
More wallets, shorter intervals or additional REST calls can exhaust its headroom.
Live market feeds and Hyperliquid account state
GoldRush's Streaming API fits continuous market and wallet monitoring on supported chains and decentralized exchanges. Its feeds include new trading pairs, liquidity changes and wallet activity. OHLCV feeds provide open, high, low, close and volume values for supported tokens or pairs. GraphQL subscriptions run over WebSocket using the
graphql-transport-ws
protocol, although stream coverage remains specific to the chain and feed; REST balance support doesn't establish support for every live subscription.
A Hyperliquid account-state batch doesn't turn every Foundational wallet query into a batch request.
The separate Hyperliquid service supports REST account-state batches for up to 50 wallets per call and market or wallet WebSocket streams. Its replacement interfaces advertise no REST rate limits and no per-IP WebSocket subscription cap. Those conditions belong to that service, not the general Foundational API. HyperCore account state and HyperEVM token data also describe different objects, even when the application presents them together.
When does warehouse delivery fit Solana analysis?
GoldRush's Solana warehouse delivery fits analyses built from decoded decentralized-exchange swaps and SPL token-transfer records. SPL means Solana Program Library. The service delivers normalized swaps and transfers to destinations including ClickHouse, BigQuery, Postgres, Kafka, S3 and webhooks. These records support queries and downstream processing of the delivered activity. The destination and configured dataset determine what the application receives.
A balance display has a different input: Foundational REST supplies SPL token holdings and native SOL for a base58 wallet address. Stored swap and transfer records suit retrospective analysis. A supported live feed suits monitoring events as they arrive. These options need their own coverage assessment; choosing a warehouse destination doesn't broaden the supported data types or make every chain available through the same interface.
NFT displays and allowance monitoring
GoldRush's NFT and Security APIs support collection displays and approval monitoring where fungible balances leave out relevant details. NFT data includes media, metadata, ownership and sales information, with trait filters and thumbnail previews. On applicable chains, an approval screen can display ERC20 and NFT allowances with value-at-risk information. Querying an allowance reads an existing permission; it doesn't revoke that permission. Chain and token-standard support determines which records a collection display or approval screen can show.
When should an app use raw JSON-RPC?
GoldRush JSON-RPC fits applications needing node methods, including contract calls, raw account data and execution traces.
On EVM networks, methods such as
eth_call
and
eth_getBalance
expose node-level operations. Solana has its own methods, including
getAccountInfo
. Applications compose these calls and interpret their results. Foundational REST supplies decoded records and pricing when its endpoints already cover the required dataset. The RPC service routes requests among upstream providers by chain and method. Archive access, debugging and tracing need the relevant network's RPC support; the wider Foundational chain catalogue isn't a promise of identical RPC method coverage.
API access, terminal use and throughput
Subscription-based GoldRush access requires an API key. The free trial provides 14 days of evaluation access for prototypes. The CLI supports terminal queries, live streaming and native MCP integration for AI-agent tools. MCP is the Model Context Protocol. A terminal interface can fit an interactive lookup or monitoring job, while an application integration needs credentials and request handling suited to its chosen service.
GoldRush x402 provides wallet-paid access to Foundational endpoints without an account or API key. This route runs on Base Sepolia testnet with a limit of 100 requests per minute per wallet. It fits payment-access experiments; this testnet route doesn't provide Base mainnet settlement.
The Professional plan lists a Foundational API throughput limit of 50 requests per second. Professional targets production applications and can accommodate greater scheduled REST demand. Vibe Coding is intended for personal projects; its plan guidance advises against commercial business applications. Higher throughput doesn't add an unsupported historical enrichment or live feed. A job may need a different interface or plan when request volume grows, its freshness target tightens or the required data falls outside the selected service's coverage.
Covalent: common questions
How should an app interpret raw token balances in GoldRush responses?
Raw token balances are integer strings expressed in the token's smallest unit. Divide the balance by 10 raised to contract_decimals to obtain token units, using arithmetic that preserves precision. A quote field expresses a currency valuation, so it shouldn't be displayed as the token quantity.
Will one GoldRush API credit always equal one request?
API credits and requests measure different things. Endpoint charges can apply per call or per returned item, with different rates across endpoints. Throughput measures requests over time. A workload can remain within its RPS limit while consuming its included credits, so capacity and credit usage need separate estimates.
What does updated_at mean in a GoldRush balance response?
The updated_at field records when the balance response was generated. It differs from the application's fetch time or screen-rendering time. The response also exposes chain_tip_height and chain_tip_signed_at for the latest chain block reported with it. These fields help distinguish response age from chain progress without treating a redraw as a data refresh.
Are REST chain names valid unchanged in GraphQL stream queries?
REST chain names and Streaming API enums use different formats. Base uses base-mainnet in REST and BASE_MAINNET in the streaming interface. A supported REST name therefore needs the streaming interface's corresponding enum where available. Changing the spelling doesn't create support for a chain or feed the streaming service doesn't cover.
Can archived chain records support live wallet monitoring?
Archived chain records support historical analysis without supplying live updates. A monitor requiring new balances or transactions needs an actively supported data source for that chain. Archived records can remain useful for past activity, but polling those records more often doesn't turn the archive into a live feed.
Why does a higher RPS limit leave transaction pagination necessary?
A higher request limit changes throughput, not the number of records an endpoint returns in each response. Paginated transaction endpoints still require the endpoint's pagination mechanism to retrieve additional records. Capacity estimates need to include those extra requests, rather than counting one initial call as the complete transaction-history workload.
Must an app stake CXT before making GoldRush subscription queries?
GoldRush subscription queries authenticate with an API key rather than a CXT staking position. CXT staking and delegation concern participation in the network's security and rewards. Holding or delegating the token doesn't replace the API credential an application uses to request wallet data.
Does Covalent's GoldRush token-spam filter work on every supported chain?
The token-balance endpoint's no-spam option is supported on Foundational Chains. It removes tokens classified as suspected spam from that response when enabled. A filtered balance display and complete asset accounting have different requirements: excluding suspected spam changes the displayed inventory and doesn't certify every remaining token.