Introducing Feeds: Enriched Onchain Datasets via API and Streaming

Products that touch wallets typically ask:

1. What has this address moved?
2. What does it hold right now?

Answering these has always been reasonably easy. RPC endpoints, indexers and wallet APIs have been around nearly as long as the chains themselves.

However, customers kept coming to us over a few challenges from existing solutions:

• API downtime – For digital asset and stablecoin infrastructure products, not showing a balance to a customer continues to be a P0 event.
• Unsupported contracts and addresses – Certain addresses and high-volume contracts are unsupported by other APIs, and there’s no way to know in advance if a request will fail.
• Coverage gaps – Unsupported chains, token standards, and fields.
• Separate integrations per chain – Teams run one API for some EVM chains, and others for Solana, HyperEVM, etc. and maintain the mapping layer between the various schemas and chain-specific quirks.
• Enrichment bought separately – Spam indicators, token metadata, and prices often require a separate subscription, each with their own integration and code to maintain.
• Minimums and complicated billing – Providers charge a minimum floor whether you use the allocated usage or not, plus compute units and weighted endpoints.
• Polling, caching, and latency at scale – Every read is a request to someone else’s API, so teams poll and cache on a schedule. This loop gets slower and more expensive as they scale.

We’d already been providing custom datasets that solved these problems for a select number of institutions.

Today, a broader set of enriched datasets are now available to everyone.

Wallet transfer and balance feeds now available

Goldsky Feeds is a catalog of enriched, ready-to-use onchain datasets. Each data feed answers a question, in one normalized schema, and you can call as an API or stream into your own database.

The catalog is organized by theme. Wallets & Portfolios is the first, and it’s available today with two feeds:

Transfers and balances are the first two datasets in the catalog, with more wallet data and other themes to follow.

Every feed is available two ways:

1. API – Call the endpoint and get rows back in the response
2. Streaming – Have the feed data delivered directly into a database you control, with history backfilled into the same table as new rows

When you send a wallet address to the Feeds API, you get back every transfer it’s made and every token it currently holds:

• EVM and non-EVM chains (Solana, HyperEVM, HyperCore)
• One normalized schema across all supported chains, with a chain_family field so that non-EVM chains arrive in the same format
• Managed backfills, so full history from genesis is available upon first request
• Native and ERC-20 balances with USD values on every row
• Wallet-level total: summed USD value of the tokens a wallet holds
• Every address: exchange wallets and high-volume contracts are included
• Token metadata inline: including symbol, name, decimals, and logo
• Filters for noise: hide zero balances and tokens with no market price, with token-level spam indicators coming soon
• Per-request pricing with no minimum

How the onchain data API works

There are two REST endpoints, called with your data API key.

Both accept a single address (and soon a comma-separated list) across all supported chains at once. Results page with keyset cursors at 100 rows by default and 1,000 max, and will return the same fields for both EVM and non-EVM chains. Balances responses also carry total_value_usd for each address you query, covering the tokens that have a price.

A chain_family field tells you which family a row came from, which is important for a few fields that differ. On Solana for example, token_address is the mint and block_number is the slot.

What you can do with them:

• Query many addresses in one request – address takes a single or comma-separated list, so a batch of wallets is just one call.
• Filter to what you need – By chain, token address or symbol, direction (inbound or outbound), transfer type, and a time or block range.
• Filter out dust, empty and unpriced tokens – min_value_usd hides small priced balances, and spam-flagged tokens stay out unless you ask for them with exclude_spam=false
• Page through history predictably – Keyset cursors, 100 rows by default and 1,000 max, stable while new rows arrive.
• Verify before you build – Paste an address into the playground in the dashboard, check the rows against your own records, then copy the exact request. Usage per endpoint shows up in the dashboard alongside your other products.

Streaming onchain wallet data into your own database

Streaming delivers the same feeds into a database you control, so your application reads wallet data locally without needing to call an API. Teams move to streaming for various reasons:

• Latency at scale – Reads become local queries. A reconciliation job over millions of rows runs as SQL next to your other data, with no per-request round trip and no cache to keep warm.
• Many wallets at once – Until multi-address requests ship, a workload that tracks thousands of addresses is one API request per address per poll. Streaming covers the whole tracked set in one pipeline.
• Data residency and access control – The data sits in infrastructure you own, under your own network rules, encryption and access reviews.
• Audit and retention – You keep your own copy of the history, on your own retention schedule, and you can show an auditor records from your own systems.
• Joins with internal data – Match transfers against data in your offline systems such as client accounts, KYC records or your internal ledger in a single query, which no external API can do for you.
• No polling loop – Nothing to schedule, no cache to invalidate, and no backfill pagination to maintain.

How streaming works

1. Choose the feed and what to track. Balances, Transfers or both, the chains you want, and the addresses to follow.
2. Connect a destination. Postgres, ClickHouse, Snowflake or BigQuery. We validate the connection and create the table.
3. History arrives with the live data. We backfill the full history for your tracked wallets into the same table as new rows, so there's no separate import to reconcile.
4. We handle reorgs. When a chain reorganizes, the affected rows are rolled back and re-applied in your table, so it matches the canonical chain without you writing correction logic.
5. Delivery is at-least-once. A failed delivery is retried, not dropped.
6. Manage tracked wallets and chains through the API. Add or remove addresses and chains without rebuilding the pipeline.

What lands in your database:

Managed backfills

Holding every transfer and balance for every address you might need one day is expensive. Backfilling them on demand is slow, and someone has to own the job. We run the indexing and the backfills for every supported chain, so the full history for an address is available when you first request it.

Build deposit reconciliation, portfolio screens or a second data source

Guides coming soon.

Pricing: $0.35 per 1K requests with no minimum

Pricing is usage-based with no minimum floor. A batch request counts as one request.

Coming soon to Feeds

• Solana, HyperEVM, HyperCore, and more supported chains
• Multi-address requests so you can batch wallets in one call
• Spam indicators on tokens
• More Wallet & Portfolio feeds: P&L, token balance history, holdings over time, tokens, transactions
• Other feeds: stablecoins, tokenized assets, prediction markets
• Self-serve feed streaming

Try Wallet Feeds

1. Visit Feeds in the Goldsky dashboard
2. Choose Transfers or Balances
3. Add wallet addresses you want to track
4. Query the API with your key

View the Feeds docs here (opens in a new tab).