DEV Community: moiapi

How to Build a Powerful Solana TradingView Chart in 4 Steps

moiapi — Wed, 22 Jul 2026 04:50:40 +0000

The Solana TradingView Chart API guide: resolve tokens, seed up to 5,000 OHLCV candles, backfill on scroll, and keep the live bar fresh with Birdeye Data.

Direct Answer: Build a Solana TradingView Chart in 4 Steps
Stage 1: Resolve a Token or Pair with the Search API
Stage 2: Seed 5,000 Candles with the OHLCV API
Stage 3: Backfill History on Scroll Back
Stage 4: Keep the Last Candle Live
- On any paid tier: poll the latest candle
- On Premium and up: stream over WebSocket
Stage 5: Add a Liquidity Overlay
Utility: Monitor Your CU Budget
Putting It Together: Reference Architecture
FAQ
- Which intervals does the Solana TradingView Chart API support?
- How many candles can one request return?
- How far back does candle history go?
- Do I need a WebSocket to make the chart live?
- How do I chart a specific pool instead of the token?
- Why are my older second level candles empty?

Most Solana charts break at the data layer, not the UI. The candlestick widget renders fine, but candles arrive out of order, history stops loading when the user scrolls back, and the last bar freezes because the live feed quietly dropped. The hard part of a Solana TradingView Chart API integration is the feed, not the chart.

This guide builds the Solana TradingView Chart data layer with Birdeye Data: a multi chain market data service covering real time prices, OHLCV (open, high, low, close, volume) candles, liquidity, and trade activity across Solana and major EVM networks. A Solana TradingView Chart needs four different shapes of data, and the whole pipeline runs on a handful of endpoints. Birdeye even publishes an official TradingView datafeed example at github.com/birdeye-so/tradingview-example-js-api, so the approach below is the same one their reference implementation uses.

The trick is to fetch only what is on screen: stream or poll the visible candle, and pull older history only when the user scrolls back. That keeps credit usage flat as chart traffic grows.

Direct Answer: Build a Solana TradingView Chart in 4 Steps

To build a Solana TradingView chart with Birdeye Data, you need four data layers: resolve, seed, backfill, and live.

Call GET /defi/v3/search to resolve a symbol or address to a token or pool, and GET /defi/v3/price/stats/single for the toolbar price, high/low, and percentage change.
Call GET /defi/v3/ohlcv to seed the visible viewport with up to 5,000 candles, including second level 1s, 15s, and 30s intervals on Solana.
Page GET /defi/v3/ohlcv by shifting the time window to backfill older candles on scroll, and fall back to GET /defi/history_price for very long line chart ranges.
Keep the last candle live by polling the latest OHLCV candle on an interval (any paid tier) or by streaming SUBSCRIBE_PRICE over WebSocket (Premium package and up). Optionally overlay liquidity with GET /defi/v3/liquidity/ohlc/pair.

All requests share the base URL https://public-api.birdeye.so, authenticate with the X-API-KEY header, and select the network with the x-chain header (default solana). The chart in this guide is Solana, so every header is x-chain: solana.

One access note before you wire up the live layer: REST polling drives the live candle on every tier and is the primary path in this guide. WebSocket streaming is the lower latency option, available from the Premium package up per the Data Accessibility table, which Stage 4 covers in full.

Stage 1: Resolve a Token or Pair with the Search API

Endpoint: GET /defi/v3/search, GET /defi/v3/price/stats/single
Chains: All supported networks
Docs: Token — Search, Price Stats — Single

When a user types BONK or pastes a mint, you need a canonical address before you can request anything else. Search resolves both: it returns token results and market (pool) results in one call, so you can chart either an aggregated token or one specific pool.

Key parameters for search:

\bash curl --request GET \ --url 'https://public-api.birdeye.so/defi/v3/search?chain=solana&keyword=BONK&target=token&search_by=symbol&search_mode=exact&sort_by=volume_24h_usd&sort_type=desc&offset=0&limit=20' \ --header 'accept: application/json' \ --header 'x-chain: solana' \ --header 'X-API-KEY: YOUR_API_KEY' \\

A common 400: sort_by and sort_type are both required, not optional. Forget either one and the call fails. The response groups results by type, so read data.items[], find the group where type is token, and take result[0].address. Market groups carry the pool address you will pass to the pool level OHLCV and the liquidity overlay later.

For the toolbar, price/stats/single returns price, percentage change, and high/low across one or more windows in a single call. Pass the windows you display as a comma separated list_timeframe.

\bash curl --request GET \ --url 'https://public-api.birdeye.so/defi/v3/price/stats/single?address=DezXAZ8z7PnrnRJjz3wXBoRgixCa6xjnB7YaB1pPB263&list_timeframe=1h,24h' \ --header 'accept: application/json' \ --header 'x-chain: solana' \ --header 'X-API-KEY: YOUR_API_KEY' \\

One schema gotcha for later: on Solana the stats payload is a direct array under data, while on EVM chains the same endpoint nests results under data.items. If you plan to extend the chart to EVM, branch your parser on chain now.

Now you have a canonical address and toolbar stats for your Solana TradingView Chart. Next, fill the visible chart.

Stage 2: Seed 5,000 Candles with the OHLCV API

Endpoint: GET /defi/v3/ohlcv (token), GET /defi/v3/ohlcv/pair (pool)
Chains: Solana, Base, BSC, Ethereum, Monad
Docs: OHLCV (V3)

The first paint should fill the visible viewport in one request. The V3 OHLCV endpoint returns up to 5,000 records, supports second level Solana intervals, and does not pad missing candles by default, which is exactly what a TradingView datafeed expects from its history call.

Key parameters:

\bash curl --request GET \ --url 'https://public-api.birdeye.so/defi/v3/ohlcv?address=DezXAZ8z7PnrnRJjz3wXBoRgixCa6xjnB7YaB1pPB263&type=15m&currency=usd&time_from=1726700000&time_to=1726704000&mode=range&padding=false' \ --header 'accept: application/json' \ --header 'x-chain: solana' \ --header 'X-API-KEY: YOUR_API_KEY' \\

Each item in data.items[] carries o, h, l, c, v, v_usd, and unix_time, which maps one to one onto a TradingView bar object. To chart a specific pool rather than an aggregated token, call /defi/v3/ohlcv/pair with the pool address. It takes the same time and type params, drops currency, and adds inversion to flip the base and quote sides.

With the viewport filled, handle the user scrolling back into history.

Stage 3: Backfill History on Scroll Back

Endpoint: GET /defi/v3/ohlcv, GET /defi/history_price
Chains: All supported networks
Docs: Price – Historical

When the user pans left, request an older window by shifting time_from and time_to to the period just before your earliest loaded candle, keeping the same type so the series stays continuous. TradingView calls your datafeed repeatedly as the user scrolls, so this is just the same OHLCV call with an earlier window.

For very long ranges where a candle by candle load is wasteful, fall back to history_price, which returns a lightweight line series of unixTime and value points. It takes address, address_type (token or pair), type, time_from, and time_to.

\bash curl --request GET \ --url 'https://public-api.birdeye.so/defi/history_price?address=DezXAZ8z7PnrnRJjz3wXBoRgixCa6xjnB7YaB1pPB263&address_type=token&type=15m&time_from=1726600000&time_to=1726700000' \ --header 'accept: application/json' \ --header 'x-chain: solana' \ --header 'X-API-KEY: YOUR_API_KEY' \\

Second level candles have limited retention: 1s is kept for 2 weeks, and 15s and 30s for 3 months. Cap the second level intervals to recent ranges in your UI, and switch to 1m and above for anything deeper, or backfill requests will come back empty.

Stage 4: Keep the Last Candle Live

This is the layer that makes your Solana TradingView Chart feel real time, and it is the one place where your package tier changes the implementation.

On any paid tier: poll the latest candle

Request the latest one or two candles on a short interval with mode=count, then merge the newest bar into the chart. This works on every paid tier, Standard through Enterprise, with no WebSocket.

\bash curl --request GET \ --url 'https://public-api.birdeye.so/defi/v3/ohlcv?address=DezXAZ8z7PnrnRJjz3wXBoRgixCa6xjnB7YaB1pPB263&type=1m&currency=usd&mode=count&count_limit=2&time_to=1726704000' \ --header 'accept: application/json' \ --header 'x-chain: solana' \ --header 'X-API-KEY: YOUR_API_KEY' \\

A poll interval close to the candle interval is usually enough. For a 1m chart, polling every few seconds keeps the forming bar fresh without wasting credits. Watch your budget with the credits endpoint in the next section and back off the interval if needed.

On Premium and up: stream over WebSocket

Endpoint: SUBSCRIBE_PRICE, SUBSCRIBE_TXS
Plan availability: Premium, Business, and Enterprise per the Data Accessibility table. Note: the WebSocket docs page still lists Business and up, so the two pages conflict. Confirm streaming access against your own key before relying on it.
Docs: WebSocket – Price/OHLCV

For the lowest latency live bar, open one socket and subscribe to the price stream. The chain goes in the URL path, not a header.

\javascript const ws = new WebSocket(wss://public-api.birdeye.so/socket/solana?x-api-key=${API_KEY}`,
"echo-protocol"
);

ws.onopen = () => {
ws.send(JSON.stringify({
type: "SUBSCRIBE_PRICE",
data: {
queryType: "simple",
chartType: "1m",
address: "DezXAZ8z7PnrnRJjz3wXBoRgixCa6xjnB7YaB1pPB263",
currency: "usd",
mode: "raw"
}
}));
};

ws.onmessage = (event) => {
const msg = JSON.parse(event.data);
if (msg.type === "PRICE_DATA") {
// msg.data: { eventType: "ohlcv", o, h, l, c, v, unixTime, symbol, address }
updateLastCandle(msg.data);
}
};
`\

Three things that bite people on the socket:

One subscription per message type. Sending a new SUBSCRIBE_PRICE overwrites the previous one. To follow several tokens, send a single complex query with all of them (up to 100) and resend the full list whenever it changes. Because the limit is per type, you can run SUBSCRIBE_PRICE and SUBSCRIBE_TXS on the same socket at once.
Implement ping pong. The docs explicitly recommend a ping pong keepalive so the connection is not dropped on idle network. Add reconnection with a backfill of missed candles over REST on reconnect.
Node needs headers. In the browser the Origin and Sec-WebSocket-Protocol: echo-protocol values are set for you. In Node, set them explicitly on the client.

To add a trade tape or volume markers, subscribe to SUBSCRIBE_TXS, which returns TXS_DATA events carrying blockUnixTime, owner, source, and txHash.

Stage 5: Add a Liquidity Overlay

Endpoint: GET /defi/v3/liquidity/ohlc/pair
Chains: Solana only
Docs: Liquidity OHLC – Pair

Most charts stop at price. A liquidity ribbon under the candles is a feature competitors rarely expose, and it is one call. This endpoint returns liquidity as OHLC for a Solana pool, up to 100 records per request, anchored at a timestamp and paged by direction rather than a time_from/time_to range.

\bash curl --request GET \ --url 'https://public-api.birdeye.so/defi/v3/liquidity/ohlc/pair?address=YOUR_PAIR_ADDRESS&time=1726704000&direction=back&count=100' \ --header 'accept: application/json' \ --header 'x-chain: solana' \ --header 'X-API-KEY: YOUR_API_KEY' \\

Each item carries the open, high, low, and close liquidity in USD for the window. To page older liquidity candles, set direction=back and move the time anchor to just before your earliest loaded candle; use direction=forward to move toward the present. With time omitted, the anchor defaults to the latest available candle.

Utility: Monitor Your CU Budget

Endpoint: GET /utils/v1/credits
Docs: Utils – Credits Usage

If you poll for the live layer, wire this in from day one so a tight interval does not quietly burn your budget.

\bash curl --request GET \ --url 'https://public-api.birdeye.so/utils/v1/credits' \ --header 'X-API-KEY: YOUR_API_KEY' \\

With no parameters it returns the current cycle: total usage split into REST api and WebSocket ws, remaining credits, and overage fields. A practical pattern: poll hourly and widen your live poll interval automatically if remaining credits drop below a safe threshold, rather than running into a 429 mid session.

Putting It Together: Reference Architecture

For your Solana TradingView Chart, build it in that order: paint the visible viewport first, attach the live layer last, and backfill only when the user scrolls. On any tier the live layer can be a short interval poll of the latest OHLCV candle. From Premium up you can swap that one function for a SUBSCRIBE_PRICE socket with ping pong and reconnect, and leave everything else as is.

Checklist before you ship your Solana TradingView Chart:

The history call uses padding=false so the chart does not invent flat candles.
Backfill keeps the same type, and second level intervals are capped to their retention windows.
The live layer degrades gracefully: REST poll on any tier, WebSocket from Premium up.
The price stats parser branches on chain if you target EVM later.
Credit usage is observable so a tight poll interval cannot surprise you with a 429.

FAQ

Which intervals does the Solana TradingView Chart API support?

The V3 OHLCV endpoint covers 1s through 1M, including the second level 1s, 15s, and 30s intervals on Solana that most competitors do not offer.

How many candles can one request return?

Up to 5,000 records per OHLCV V3 call. For more history, page by shifting the time window.

How far back does candle history go?

Minute and higher intervals reach far back. Second level intervals are limited: 1s for 2 weeks, 15s and 30s for 3 months.

Do I need a WebSocket to make the chart live?

No. REST polling of the latest OHLCV candle keeps the chart live on every paid tier and is the primary path here. WebSocket streaming is available from the Premium package up per the Data Accessibility table, as a lower latency option.

How do I chart a specific pool instead of the token?

Use /defi/v3/ohlcv/pair with the pool address, and set inversion if you need to flip base and quote.

Why are my older second level candles empty?

They fell outside the retention window. Switch to 1m or higher for ranges beyond the second level limits above.

You now have the full Solana TradingView Chart data layer, from first paint to live candle. Get an API key at Birdeye Data to start building, and keep the full endpoint reference handy. To skip the boilerplate, start from the official TradingView datafeed example at github.com/birdeye-so/tradingview-example-js-api.

Solana Trading Bot API: Build a Powerful 5-Stage Data Layer

moiapi — Wed, 22 Jul 2026 04:36:42 +0000

A Solana trading bot API guide with Birdeye Data: WebSocket token discovery, security gating, momentum screening, whale alerts, and Smart Money tracking.

Direct Answer: Build the Solana Trading Bot API Data Layer in 5 Stages
Stage 1: Discover New Pools and Listings in Real Time
Stage 2: Gate Every Token with Pre-Trade Security Checks
Stage 3: Screen Survivors by Momentum
Stage 4: Monitor Open Positions with Live Streams
Stage 5: Profile Holders and Track Smart Money
Utility: Monitor Your CU Budget Programmatically
Putting It Together: Reference Architecture
FAQ
- What package do I need to run this pipeline?
- Can I use the exit-liquidity endpoint for Solana tokens?
- Do I need the scroll endpoint for the screening stage?
- What does the holder endpoint actually tell me?
- Why run discovery on WebSocket instead of polling the new listing endpoint?
- How fresh are the streamed OHLCV candles?
- How do I keep CU consumption under control as the bot scales?

Every Solana trading bot API stack succeeds or fails at the data layer, not the strategy layer. Most bots poll REST endpoints for new tokens and arrive late. They enter pools without security checks and get caught by hidden taxes or mintable supply. They enrich every token they see and burn their compute unit (CU) budget on tokens that were never tradeable.

This guide builds the pipeline for a Solana trading bot API differently, using Birdeye Data: a multi-chain market data layer covering real-time prices, trades, liquidity, security data, and holder stats. The entire Solana trading bot API data layer runs on 5 stages.

The pipeline is built around one rule: each stage is a gate for the next one. A token only earns deeper (and more expensive) analysis after it survives the cheaper checks upstream. Discovery is a free-flowing stream, security gating rejects most of it, and only the survivors ever reach screening, monitoring, or holder profiling.

Direct Answer: Build the Solana Trading Bot API Data Layer in 5 Stages

To build a Solana trading bot data layer with Birdeye Data, you need 5 stages covering discovery, security gating, screening, position monitoring, and holder profiling.

Subscribe to SUBSCRIBE_NEW_PAIR and SUBSCRIBE_TOKEN_NEW_LISTING over WebSocket to stream brand-new pools and listings the moment they appear, with GET /defi/v2/tokens/new_listing as REST backfill.

Call GET /defi/token_security and GET /defi/token_creation_info to reject scams (hidden taxes, mintable supply, mutable metadata), and GET /defi/token_overview to confirm real liquidity depth before entry.

Call GET /defi/token_trending and GET /defi/v3/token/list to bulk-scan and rank survivors by volume, liquidity, and price momentum using server-side filters.

Subscribe to SUBSCRIBE_PRICE, SUBSCRIBE_TXS, and SUBSCRIBE_LARGE_TRADE_TXS for live OHLCV candles, swap flow, and whale alerts on open positions, with GET /defi/v3/ohlcv and POST /defi/multi_price on the REST side.

Call GET /defi/v3/token/holder, GET /token/v1/holder-profile, GET /defi/v2/tokens/top_traders, and GET /smart-money/v1/token/list to analyze cap table concentration, holder profiles, and what historically profitable wallets are trading.

The pipeline starts with discovery because everything downstream only consumes what discovery emits; without a fast, filtered stream of candidates, the other four stages have nothing to work on. Before diving in, two conventions apply to every call in this guide: all REST endpoints share the same base URL (https://public-api.birdeye.so), use X-API-KEY for auth, and select the network via the x-chain header. The WebSocket connects at wss://public-api.birdeye.so/socket/solana with the API key passed as a query param. This guide targets Solana, where new token velocity makes the gated pipeline matter most.

Stage 1: Discover New Pools and Listings in Real Time

Interface: WebSocket: SUBSCRIBE_NEW_PAIR, SUBSCRIBE_TOKEN_NEW_LISTING
REST backfill: GET /defi/v2/tokens/new_listing
Docs: New Pair (WSS), New Token Listing (WSS), Token — New Listing

On Solana, new tokens launch every few seconds. Polling a REST endpoint in a loop means you are always late and always paying for requests that return nothing new. Discovery for a Solana trading bot API belongs on the WebSocket, where events are pushed to you the moment they happen on-chain.

Two subscriptions cover it. SUBSCRIBE_NEW_PAIR fires whenever a new liquidity pool is created on a supported DEX, which is your earliest possible signal that a token is tradeable. SUBSCRIBE_TOKEN_NEW_LISTING fires when a token is newly listed and indexed, with optional filters for meme platforms and minimum liquidity so dust gets dropped at the socket level instead of in your own code. One plan note before you build around this: WebSocket access requires a Premium package or higher, so on lower tiers the REST backfill endpoint below becomes your discovery loop instead.

\`python
import asyncio, json, websockets

WS_URL = "wss://public-api.birdeye.so/socket/solana?x-api-key=YOUR_API_KEY"

async def discover():
async with websockets.connect(WS_URL, subprotocols=["echo-protocol"]) as ws:
await ws.send(json.dumps({"type": "SUBSCRIBE_NEW_PAIR"}))
await ws.send(json.dumps({
"type": "SUBSCRIBE_TOKEN_NEW_LISTING",
"meme_platform_enabled": True,
"min_liquidity": 1000
}))
async for message in ws:
event = json.loads(message)
if event.get("type") == "NEW_PAIR_DATA":
# the tradeable token is the base leg; data.address is the pair itself
handle_candidate(event["data"]["base"]["address"])
elif event.get("type") == "TOKEN_NEW_LISTING_DATA":
handle_candidate(event["data"]["address"])
`\

Two details that are easy to get wrong here. First, the filter parameters (min_liquidity, max_liquidity, meme_platform_enabled, sources) sit at the top level of the subscription message, not inside a data object; SUBSCRIBE_NEW_PAIR accepts the same liquidity bounds. Second, in NEW_PAIR_DATA the new token is data.base.address, while data.address is the pool address. Pushing the wrong one into your queue sends pool addresses through your security gate.

For cold starts and reconnects, backfill from REST instead of replaying the socket (the limit parameter caps at 20 per call, default 10):

\bash curl --request GET \ --url 'https://public-api.birdeye.so/defi/v2/tokens/new_listing?limit=20' \ --header 'X-API-KEY: YOUR_API_KEY' \ --header 'x-chain: solana' \ --header 'accept: application/json' \\

One architectural note before you wire this up: the output of this stage is nothing more than a stream of candidate addresses pushed into a queue. The discovery consumer in your Solana trading bot API should never act on a token directly, because most of what comes through this stream is about to fail the next gate.

Stage 2: Gate Every Token with Pre-Trade Security Checks

Endpoints: GET /defi/token_security, GET /defi/token_creation_info, GET /defi/token_overview
Chains: token_security covers all supported networks except Sui; token_creation_info currently supports Solana only
Docs: Token — Security, Token — Creation Info, Token — Overview, Security Data Glossary

This is the stage that protects your capital in any Solana trading bot API, and it is where the CU gating logic earns its keep. A new Solana token can look perfectly healthy on a chart while hiding a transfer tax, a mintable supply, or a creator wallet holding most of the float. Three checks, run in sequence, filter the stream down to tokens that are actually safe to touch. Note that token_security and token_creation_info are available from Lite/Starter packages and above; they are not included in the free Standard tier.

Check 1: security profile. GET /defi/token_security returns mint and freeze authority status, transfer fee configuration, metadata mutability, top holder concentration, and creator balances. A minimal rule set for a bot:

One thing to internalize about this response: on Solana there is no literal mintable boolean. Mintability is derived from ownerAddress (null means renounced, no further minting possible), and null generally signals the absence of a risk, so a null transferFeeEnable or freezeable is safe, not missing data. The full field definitions live in the Security Data Glossary linked above.

\bash curl --request GET \ --url 'https://public-api.birdeye.so/defi/token_security?address=TOKEN_ADDRESS' \ --header 'X-API-KEY: YOUR_API_KEY' \ --header 'x-chain: solana' \\

Check 2: creator history. GET /defi/token_creation_info returns the creation transaction, timestamp, and the wallet that deployed the token. Cross-referencing the creator address against your own blacklist of serial ruggers is one of the highest ROI checks a bot can run, and it costs a single call.

Check 3: liquidity depth. A token can pass every security check and still be untradeable because there is no real exit. GET /defi/token_overview returns liquidity in USD alongside price, volume, trade counts, and unique wallets, so the gate can enforce a hard liquidity floor:

\bash curl --request GET \ --url 'https://public-api.birdeye.so/defi/token_overview?address=TOKEN_ADDRESS&frames=1h,24h' \ --header 'X-API-KEY: YOUR_API_KEY' \ --header 'x-chain: solana' \\

Use the frames parameter here. The gate only needs one or two timeframes, and narrowing frames shrinks the response payload. On the CU side, token_overview is actually the cheapest of the three gate calls (25 CU, versus 40 for token_security and 50 for token_creation_info at the time of writing), so the gate runs the strongest filter first rather than the cheapest. Current prices are listed on the Compute Unit Cost page and are subject to change.

Note for multi-chain builders: Birdeye Data also offers GET /defi/v3/token/exit-liquidity, which estimates how much value can realistically be extracted from a pool. That endpoint currently supports Base only. On Solana, the combination of token_security (holder concentration, LP data) and token_overview (liquidity depth) is the right approach, and this guide uses it throughout.

Tokens that clear all three checks are real, tradeable, and not obviously hostile. Stage 3 decides whether they are worth trading.

Stage 3: Screen Survivors by Momentum

Endpoints: GET /defi/token_trending, GET /defi/v3/token/list
Chains: token_trending covers all supported networks; this guide uses v3/token/list on Solana
Docs: Token — Trending List, Token — List (V3)

Passing the security gate makes a token safe for your Solana trading bot API. It does not make it a good trade. The screening stage ranks candidates by momentum so your Solana trading bot API spends attention where volume and flow actually are.

GET /defi/token_trending gives you the market's attention in one call: a pre-ranked list sortable by rank, volumeUSD, or liquidity over 1h, 4h, or 24h windows. For a sniper-style bot, interval=1h surfaces breakout tokens far earlier than the 24h board.

\bash curl --request GET \ --url 'https://public-api.birdeye.so/defi/token_trending?sort_by=rank&sort_type=asc&interval=1h&limit=50' \ --header 'X-API-KEY: YOUR_API_KEY' \ --header 'x-chain: solana' \\

For systematic scanning, GET /defi/v3/token/list is the workhorse. It returns up to 100 tokens per request and pushes all filter logic to the server: liquidity bounds, market cap and FDV ranges, holder counts, listing age, multi-window volume and volume-change filters, price momentum, and trade counts. Both sort_by and sort_type are required, so a missing sort param returns a 400.
A practical "tradeable small caps with momentum" scan on Solana:

\bash curl --request GET \ --url 'https://public-api.birdeye.so/defi/v3/token/list?sort_by=volume_24h_change_percent&sort_type=desc&min_liquidity=50000&min_holder=500&min_volume_24h_usd=100000&min_trade_24h_count=1000&limit=100' \ --header 'X-API-KEY: YOUR_API_KEY' \ --header 'x-chain: solana' \\

The response per item is already dense (price, liquidity, market_cap, fdv, holder, multi-window volume, price change, and trade counts), so your ranking logic can run entirely from one scan without per-token follow-up calls.

Scaling up: if you are on a Business or Enterprise package, GET /defi/v3/token/list/scroll exposes the same filters and sorts but returns up to 5,000 tokens per batch with scroll-based pagination. For full-market scans it cuts the request count by 50x. The funnel logic is identical, so starting on v3/token/list and upgrading to scroll later requires no architectural change beyond pagination handling. For a build that revolves entirely around bulk scanning, see our guide on building a token screener with Birdeye Data.

The output of this stage is a ranked shortlist. When the strategy layer opens a position on one of them, Stage 4 takes over.

Stage 4: Monitor Open Positions with Live Streams

Interface: WebSocket: SUBSCRIBE_PRICE, SUBSCRIBE_TXS, SUBSCRIBE_LARGE_TRADE_TXS
REST: GET /defi/v3/ohlcv, GET /defi/price, POST /defi/multi_price
Docs: Token/Pair OHLCV (WSS), Track Large Transactions (WSS), OHLCV V3, Price — Multiple

The moment your Solana trading bot API opens a position, the data problem changes shape. You no longer care about ten thousand tokens; you care about a handful, with maximum freshness. That workload belongs on the WebSocket.

Three subscriptions cover a live position in your Solana trading bot API:

SUBSCRIBE_PRICE streams live OHLCV candles for a token or pair at intervals from 1 second upward. This drives stop loss, take profit, and trailing logic with zero polling.

SUBSCRIBE_TXS streams every swap on the token as it happens, which is how you detect sudden one-sided flow like a wall of sells from fresh wallets.

SUBSCRIBE_LARGE_TRADE_TXS is the whale alarm. You set a minimum volume and only receive trades above it:

\`python
await ws.send(json.dumps({
"type": "SUBSCRIBE_PRICE",
"data": {
"queryType": "simple",
"chartType": "1m",
"address": TOKEN_ADDRESS,
"currency": "usd"
}
}))

await ws.send(json.dumps({
"type": "SUBSCRIBE_LARGE_TRADE_TXS",
"min_volume": 10000 # mandatory; optional max_volume caps the range
}))
`\

Two production gotchas on these subscriptions. For SUBSCRIBE_PRICE, a new subscription message replaces the previous one on the same connection, so to monitor several positions you must resend the full address list every time (use the complex query type, up to 100 addresses per subscription) rather than sending one message per token. For SUBSCRIBE_LARGE_TRADE_TXS, note that min_volume is mandatory and sits at the top level of the message, and the resulting TXS_LARGE_TRADE_DATA events cover all tokens that clear the volume threshold, so your handler must filter by the addresses of your open positions client-side. Each event carries both legs of the swap, the trader address, the pool, and volumeUSD, which is everything the reaction logic needs without a follow-up call.

A single whale dump into thin liquidity can move a microcap 40% in one block. Reacting to the large trade event instead of waiting for the next candle close is often the difference between a controlled exit and a stop loss filled far below its trigger.

REST fills the gaps around the stream. GET /defi/v3/ohlcv backfills candle history so indicators can be computed at startup or after a reconnect. GET /defi/price answers one-off spot price checks. And POST /defi/multi_price keeps portfolio accounting cheap: up to 100 tokens per request, with include_liquidity=true available as a query param. If the PnL side is your main interest, we cover it end to end in our Solana portfolio tracker guide.

\bash curl --request POST \ --url 'https://public-api.birdeye.so/defi/multi_price?include_liquidity=true' \ --header 'X-API-KEY: YOUR_API_KEY' \ --header 'x-chain: solana' \ --header 'content-type: application/json' \ --data '{"list_address": "ADDRESS_1,ADDRESS_2,ADDRESS_3"}' \\

One gotcha worth handling explicitly: unknown or unsupported tokens come back as null on their key in the multi_price response, not as an error. If your PnL loop does not guard against this, a single delisted token will crash the whole refresh tick.

Streams and prices tell you what is happening to your position. The last stage tells you who is behind it.

Stage 5: Profile Holders and Track Smart Money

Endpoints: GET /defi/v3/token/holder, GET /token/v1/holder-profile, GET /defi/v2/tokens/top_traders, GET /smart-money/v1/token/list
Chains: holder-profile and the Smart Money list are Solana only; PnL-based sorting on top_traders is also Solana only
Docs: Token — Holder (V3), Token — Holder Profile, Token — Top Traders, Smart Money — Token List

The final stage of your Solana trading bot API answers a question charts cannot: who actually owns this token, and are the wallets that matter buying or selling?

GET /defi/v3/token/holder returns the holder list with each wallet's balance. That is enough to compute cap table concentration: how much of the supply sits in the top 10 or top 50 wallets, and how that distribution shifts while you hold a position. A token whose top holders are quietly shrinking their balances while price grinds up is telling you something the candle chart will not.

For a richer view on top of raw balances, GET /token/v1/holder-profile (Solana only, available from Starter packages and above, with the token passed as token_address) returns a holder profile summary alongside the token's market data: holder counts, total holdings as a share of supply, and aggregated top 10 holder stats in a single call. It pairs naturally with the holder list: use v3/token/holder for the full cap table, then holder-profile for the summarized view your dashboard or alerting logic reads on each tick.

GET /defi/v2/tokens/top_traders shows the wallets with the highest trading activity on the token over a chosen window. It sorts by volume_usd as well as PnL fields (total_pnl, unrealized_pnl, realized_pnl), with timeframes from 2 days to 90 days on Solana. Tracking whether those specific wallets are net buyers or net sellers is a far stronger signal than aggregate volume alone.

GET /smart-money/v1/token/list flips the direction of the question. Instead of asking "who trades this token," it asks "what are historically profitable wallets trading right now," returning tokens ranked by Smart Money activity. It is available from Starter packages and above, Solana only. Valid sort_by values are net_flow, smart_traders_no (the default), and market_cap; interval accepts 1d, 7d, or 30d; and trader_style segments the smart money cohort into risk_averse, risk_balancers, and trenchers, so a memecoin bot and a majors bot can follow entirely different wallet populations. Page size caps at 20.

\bash curl --request GET \ --url 'https://public-api.birdeye.so/smart-money/v1/token/list?sort_by=net_flow&sort_type=desc&interval=1d&trader_style=all' \ --header 'X-API-KEY: YOUR_API_KEY' \ --header 'x-chain: solana' \\

Feeding this list back into Stage 3 as an additional screening signal closes the loop: the bot is no longer just following volume, it is following the wallets that have repeatedly been right.

Profiling is the slowest-cadence stage in the pipeline. Holder distributions do not change second to second, so running it on open positions every few minutes (rather than on every screened token) keeps its CU footprint small relative to its signal value.

With all five stages running, one piece remains: visibility into what the whole pipeline actually costs.

Utility: Monitor Your CU Budget Programmatically

Endpoint: GET /utils/v1/credits
Docs: Utils — Credits Usage

A five-stage Solana trading bot API pipeline has five different consumption profiles, and without visibility you will not know which one is burning budget. Wire this endpoint into your monitoring from day one.

\bash curl --request GET \ --url 'https://public-api.birdeye.so/utils/v1/credits' \ --header 'X-API-KEY: YOUR_API_KEY' \\

With no parameters it returns the current billing cycle: total usage broken down into REST api and WebSocket ws, remaining credits, and overage fields. The REST/WS split is particularly useful for a bot, since Stages 1 and 4 live on the socket while Stages 2, 3, and 5 live on REST.

A practical pattern: poll hourly and alert below a safe threshold. When credits run low, degrade in priority order. Slow down Stage 3 scanning first, stretch Stage 5 profiling cadence second, and leave Stage 4 position monitoring untouched until last. Your screening can wait an extra minute; your stop loss cannot.

Here is how the five stages of the Solana trading bot API pipeline and the budget loop connect into a single deployable architecture.

Putting It Together: Reference Architecture

The WebSocket consumer pushes candidates into a queue and never trades directly. A gate worker drains the queue and discards most of it. A screening cron ranks survivors and feeds the strategy. Each open position gets its own monitoring subscriptions, with multi_price batching the portfolio PnL tick. Profiling enriches open positions on a slow cadence, and the credits endpoint watches everything.

Code review checklist before you ship your Solana trading bot API:

Discovery only writes to the queue; no trades fire from the socket consumer.
Every candidate passes token_security and a liquidity floor before any screening or entry logic sees it.
Screening uses server-side filters on v3/token/list; no client-side filtering of bulk downloads.
Stop loss and whale reaction logic run off the WebSocket, never off a REST polling loop.
null responses from multi_price are handled explicitly, not assumed away.
Credit usage is observable, with a defined degradation order that protects position monitoring.

FAQ

What package do I need to run this pipeline?

For a Solana trading bot API, the WebSocket stages (Discover and Monitor) require a Premium package or higher; on lower tiers, replace them with REST polling of new_listing and multi_price at a slower cadence. The REST gate and screening stages run from Lite/Starter and above (token_security and token_creation_info are not in the free Standard tier), and the scroll variant of token list requires Business or Enterprise. The full matrix is on the Data Accessibility by Packages page.

Can I use the exit-liquidity endpoint for Solana tokens?

Not yet. GET /defi/v3/token/exit-liquidity currently supports Base only. On Solana, approximate the same judgment by combining token_security (top holder concentration, LP information) with token_overview (liquidity in USD), and enforce a hard liquidity floor in your gate before entry.

Do I need the scroll endpoint for the screening stage?

No. GET /defi/v3/token/list exposes the full filter and sort parameter set at up to 100 tokens per call, which covers most bots. The scroll variant (/defi/v3/token/list/scroll, up to 5,000 tokens per batch) is available on Business and Enterprise packages and matters mainly for full-market scans. The filters are identical, so upgrading later does not change your funnel logic.

What does the holder endpoint actually tell me?

GET /defi/v3/token/holder returns the holder list and how much each wallet currently holds, which is what you need for cap table concentration math. For a summarized holder view beyond the raw list, pair it with GET /token/v1/holder-profile (Solana only, Starter packages and above).

Why run discovery on WebSocket instead of polling the new listing endpoint?

Latency and cost. New Solana tokens launch every few seconds, so a polling loop is either too slow to be competitive or too frequent to be affordable. The WebSocket pushes NEW_PAIR and TOKEN_NEW_LISTING events the moment they occur, and the REST endpoint is reserved for backfill after restarts or reconnects.

How fresh are the streamed OHLCV candles?

SUBSCRIBE_PRICE supports intervals from 1 second upward, streamed as trades happen. For indicator warm-up at startup, backfill history with GET /defi/v3/ohlcv and then switch to the stream, so your indicators never run on stale polled data.

How do I keep CU consumption under control as the bot scales?

Gate aggressively and degrade in order. This is the core discipline of CU management for any Solana trading bot API. The pipeline is designed so the cheap stages (discovery, security gate) reject most tokens before the expensive ones (overview enrichment, profiling) ever run. Monitor with GET /utils/v1/credits, and when budget runs low, slow screening and profiling first while keeping live position monitoring untouched.

Explore the full endpoint catalog in the Birdeye Data API reference or compare data packages at birdeye.so/data-api.

Solana Portfolio Tracker: The Easy 4-Step Build Guide

moiapi — Wed, 22 Jul 2026 04:21:58 +0000

Step-by-step developer guide to building a Solana portfolio tracker with Birdeye Data: wallet holdings and net worth in one call, a 90-point net worth chart, server-computed PnL with win rate, and lazy-loaded price sparklines under the Wallet API beta rate limit.

Direct Answer: Solana Portfolio Tracker: The Easy 4-Step Build Guide
Step 1: Fetch Wallet Holdings with the Current Net Worth API
Step 2: Plot the Net Worth Chart
Step 3: Calculate Wallet PnL with the PnL Details API
Step 4: Render Token Sparklines with the Historical Price API
Utility: Monitor Your CU Budget Programmatically
Putting It Together: Reference Architecture
FAQ
- Which Birdeye Data API returns all token holdings of a Solana wallet?
- Is the old Wallet PnL GET endpoint still supported?
- What is the rate limit for Birdeye Wallet APIs?
- Do I need to normalize token balances by decimals myself?
- How do I keep dust tokens out of the portfolio view?
- Does Wallet PnL work on EVM chains?
- Can I track multiple wallets at once?

A portfolio tracker is the feature users open first and refresh most, and it is also where most wallet apps quietly fall apart. They index transactions themselves, reconcile token accounts by hand, recompute cost basis on every load, and then discover that none of it survives contact with a wallet holding 200 tokens.

This guide builds the data layer for a Solana portfolio tracker differently, using Birdeye Data: a multi-chain market data layer covering real-time prices, liquidity, and trade activity across Solana and major EVM networks, plus wallet holdings and net worth history on Solana, with server-computed PnL extending to major EVM networks as well. The entire tracker runs on 4 endpoints.

The pipeline is built around one rule: load the three wallet calls in parallel, lazy-load everything else. Wallet endpoints are in beta with a hard cap of 5 requests per second and 75 requests per minute on every plan. Spending that budget on anything besides core data is how a Solana portfolio tracker ends up rate-limited with one user on screen.

Direct Answer: Solana Portfolio Tracker: The Easy 4-Step Build Guide

To build a Solana portfolio tracker with Birdeye Data, you need 4 endpoints covering holdings, history, performance, and per-token charts.

Call GET /wallet/v2/current-net-worth to pull every token in the wallet with balances, prices, and USD values, plus the authoritative total net worth, in a single response.
Call GET /wallet/v2/net-worth to plot historical net worth, up to 90 data points at hourly or daily resolution with percent changes precomputed.
Call POST /wallet/v2/pnl/details to get server-computed PnL: win rate, total invested, realized and unrealized profit, broken down per token for up to 100 tokens.
Call GET /defi/history_price to render mini price sparklines per token, lazy-loaded for visible rows only.

The pipeline starts with the net worth call because one request hydrates the entire top half of the UI: the headline total and the full holdings table come from the same response. Everything else builds on that.

All endpoints share the same base URL (https://public-api.birdeye.so), use X-API-KEY for auth, and select the network via the x-chain header. The three /wallet/v2/ endpoints in this guide are Solana-focused and available on every plan, but they sit in a beta group with its own rate limit: 5 requests per second and 75 requests per minute, regardless of package. history_price is a standard market data endpoint outside that group, which is exactly why Step 4 is architected differently.

Step 1: Fetch Wallet Holdings with the Current Net Worth API

Endpoint: GET /wallet/v2/current-net-worth
Chains: Solana
Docs: Wallet — Current Net Worth

One call here does the work of two. The response gives you total_value (the wallet's net worth in USD), a current_timestamp, and an items array where each token includes address, decimals, price, balance (raw units as a string), amount (human-readable, already normalized by 10^-decimals), name, symbol, logo_uri, and value (USD value of the holding). Everything your holdings table renders is in there, and the headline number above it comes free.

Key parameters:

\bash curl --request GET \ --url 'https://public-api.birdeye.so/wallet/v2/net-worth?wallet=YOUR_WALLET&count=30&type=1d&direction=back&sort_type=asc' \ --header 'X-API-KEY: YOUR_API_KEY' \ --header 'x-chain: solana' \\

The count ceiling of 90 maps cleanly to the standard tracker timeframes: count=7&type=1d for the week view, count=30 for the month, count=90 for the quarter, and count=24&type=1h for an intraday view. Each timeframe is a single API call, so switching tabs in the UI is one request, not a refetch of the whole portfolio.

The total and the chart tell users what they have. The next step tells them whether they are actually winning.

Step 3: Calculate Wallet PnL with the PnL Details API

Endpoint: POST /wallet/v2/pnl/details
Chains: Solana and major EVM networks (x-chain: ethereum, base, bsc, arbitrum, polygon, optimism, avalanche, and more)
Docs: Wallet – PnL Details

This is where Solana portfolio trackers either earn trust or lose it. Users forgive a slow chart; they do not forgive a wrong PnL number. Birdeye computes realized and unrealized PnL server-side from swap activity, so you consume structured results instead of reconstructing cost basis from raw transactions.

A companion endpoint, GET /wallet/v2/pnl/summary, returns the wallet-level PnL figure on its own (docs). In practice you rarely need it for this build, because the details endpoint already returns the same wallet-level summary alongside the per-token rows, which is the CU optimization at the heart of this step.

Deprecation warning: the older GET /wallet/v2/pnl (PnL Per Token) endpoint is marked deprecated in the official OpenAPI spec, and it caps at 50 tokens per request versus 100 on the POST. If you have existing code calling the GET version, migrate to POST /wallet/v2/pnl/details now rather than after it breaks.

Key request body fields:

\bash curl --request POST \ --url 'https://public-api.birdeye.so/wallet/v2/pnl/details' \ --header 'X-API-KEY: YOUR_API_KEY' \ --header 'x-chain: solana' \ --header 'content-type: application/json' \ --data '{ "wallet": "YOUR_WALLET", "duration": "30d", "limit": 100 }' \\

The response is unusually dense. For each token you get counts (buys, sells, total trades), quantity (bought, sold, current holding, already normalized by decimals), cashflow_usd (total invested, total sold, current value), pnl (realized profit in USD and percent, unrealized, combined total, average profit per trade), and pricing (current price, average buy cost, average sell cost).

The production shortcut hiding in this response: the payload also includes a top-level summary object covering the whole wallet, with unique_tokens, trade counts including total_win, total_loss, and win_rate, plus aggregate cashflow_usd and pnl figures. One POST populates both the headline performance card and the per-token PnL table. Under a wallet budget of 75 requests per minute, getting two UI sections from one call is exactly the kind of consolidation you want.

One more thing worth wiring up: point your UI's 24h / 7d / 30d / 90d / All tabs directly at the duration field and users get timeframe-scoped performance with one request per tab switch.

Core data is now complete in three wallet calls. The last step adds the visual polish, and it deliberately runs on a different budget.

Step 4: Render Token Sparklines with the Historical Price API

Endpoint: GET /defi/history_price
Chains: All supported networks
Docs: Price – Historical

Sparklines are the small 24h or 7d line charts your Solana portfolio tracker shows next to each token row. Each one needs its own history_price call, which is why this step must be architected differently from the first three.

Key parameters:

\bash curl --request GET \ --url 'https://public-api.birdeye.so/defi/history_price?address=So11111111111111111111111111111111111111112&address_type=token&type=1H&time_from=1780963200&time_to=1781049600' \ --header 'X-API-KEY: YOUR_API_KEY' \ --header 'x-chain: solana' \\

The response is a clean array of {unixTime, value} points, which maps directly into any charting library without transformation. For a 24h sparkline, type=1H over a 24-hour window returns 24 points, plenty of resolution at sparkline size.

Why sparklines are deferred, with the actual rate limit math: two separate limits are in play. The /wallet/v2/ group is capped at 5 requests per second and 75 per minute on every plan, and your three core calls fit easily. history_price is not a wallet endpoint, so it never touches that cap; it counts against your account-level limit instead, which depends on your package (15 req/sec on Lite and Starter, 50 on Premium, 100 on Business). The catch is that the account limit is shared across all APIs. A wallet holding 40 tokens means 40 sparkline calls, and firing them all at once on a Lite plan saturates the account limit for nearly 3 seconds, starving every other request your app makes, wallet calls included.

The fix is to lazy-load: fetch sparklines only for rows currently visible in the viewport, throttle the queue to a fraction of your package's req/sec, and cache results, since a 24h sparkline does not need refreshing more than every few minutes.

With the pipeline running, you need one more thing: visibility into how much CU budget all four steps are actually consuming.

Utility: Monitor Your CU Budget Programmatically

Endpoint: GET /utils/v1/credits
Docs: Utils – Credits Usage

Solana portfolio trackers are refresh-heavy by nature, so wire credit monitoring in from day one. Poll this endpoint on a schedule and you will know a popular wallet page is burning through the monthly compute unit budget before your users find out the hard way.

\bash curl --request GET \ --url 'https://public-api.birdeye.so/utils/v1/credits' \ --header 'X-API-KEY: YOUR_API_KEY' \\

With no parameters it returns the current billing cycle: total usage broken down into REST api and WebSocket ws, remaining credits, and overage_usage/overage_cost. You can also pass time_from/time_to as unix timestamps to query up to one year back, though remaining and overage fields return null for windows outside the current cycle.

A practical pattern: poll hourly and alert if remaining credits drop below a safe threshold. If they do, automatically widen the sparkline refresh interval rather than letting the tracker run into a 429.

Here is how all four steps connect into a single loading sequence for your Solana portfolio tracker.

Putting It Together: Reference Architecture

The loading sequence in JavaScript:

\`javascript
const BASE = "https://public-api.birdeye.so";
const HEADERS = {
"X-API-KEY": process.env.BIRDEYE_API_KEY,
"x-chain": "solana",
};

async function loadPortfolio(wallet) {
// Core data: 3 wallet calls in parallel, well under 5 req/sec
const [networth, chart, pnl] = await Promise.all([
fetch(${BASE}/wallet/v2/current-net-worth?wallet=${wallet}&sort_type=desc&limit=100, { headers: HEADERS }),
fetch(${BASE}/wallet/v2/net-worth?wallet=${wallet}&count=30&type=1d&sort_type=asc, { headers: HEADERS }),
fetch(${BASE}/wallet/v2/pnl/details, {
method: "POST",
headers: { ...HEADERS, "Content-Type": "application/json" },
body: JSON.stringify({ wallet, duration: "30d", limit: 100 }),
}),
]).then(rs => Promise.all(rs.map(r => r.json())));

return {
totalValue: networth.data.total_value,
holdings: networth.data.items,
history: chart.data.history,
pnlSummary: pnl.data.summary, // win_rate, total_invested, total profit
pnlPerToken: pnl.data.tokens,
};
}

// Sparklines: lazy-loaded per visible row, throttled, cached
async function loadSparkline(tokenAddress, fromUnix, toUnix) {
const url = ${BASE}/defi/history_price?address=${tokenAddress} +
&address_type=token&type=1H&time_from=${fromUnix}&time_to=${toUnix};
const res = await fetch(url, { headers: HEADERS });
const json = await res.json();
return json.data.items; // [{unixTime, value}, ...]
}
`\

Render order matters for perceived speed: paint the total value and holdings table the moment Promise.all resolves, draw the net worth chart and PnL cards from the same batch, then stream sparklines in as each one arrives. Users see a complete Solana portfolio in one round trip and the decorative layer fills in behind it.

Code review checklist before you ship your Solana portfolio tracker:

Core data loads through one Promise.all of exactly three wallet calls, nothing more.
limit=100 is set on current-net-worth and pagination.total is checked for whale wallets.
PnL goes through POST /wallet/v2/pnl/details; no code path references the deprecated GET /wallet/v2/pnl.
Sparklines fetch only visible rows, throttled below the package req/sec, with a few minutes of caching.
Credit usage is observable, so degradation is controlled instead of a surprise 429.

FAQ

Which Birdeye Data API returns all token holdings of a Solana wallet?

GET /wallet/v2/current-net-worth returns the full portfolio of a wallet: every token with its balance, current price, and USD value, plus the wallet's total net worth, in one call. This is the core data your Solana portfolio tracker needs. Results are paginated up to 100 tokens per page.

Is the old Wallet PnL GET endpoint still supported?

GET /wallet/v2/pnl is marked deprecated in Birdeye's OpenAPI spec. Use POST /wallet/v2/pnl/details instead: it supports up to 100 tokens per request versus 50 on the deprecated GET, adds a duration filter from 24h to all, and returns a wallet-level summary object alongside the per-token breakdown.

What is the rate limit for Birdeye Wallet APIs?

All Wallet APIs are currently in beta and limited to 5 requests per second and 75 requests per minute, on every package tier. Standard market data endpoints like /defi/history_price are not part of the wallet group and instead count against your account-level limit: 15 req/sec on Lite and Starter, 50 on Premium, 100 on Business.

Do I need to normalize token balances by decimals myself?

No for display values in your Solana portfolio tracker: the amount field in the holdings response and all quantity fields in PnL responses are already normalized by 10^-decimals. The raw balance field (a string in base units) is also provided if you need exact integer math.

How do I keep dust tokens out of the portfolio view?

Pass filter_value with a minimum USD threshold on GET /wallet/v2/current-net-worth. The endpoint also excludes low-liquidity tokens under $100 by default unless you opt in with flags=include_low_liquidity.

Does Wallet PnL work on EVM chains?

Yes. POST /wallet/v2/pnl/details supports EVM networks through the x-chain header, including ethereum, base, bsc, arbitrum, polygon, optimism, and avalanche. The holdings and net worth chart endpoints in this guide remain Solana only, so an EVM build would pair the PnL endpoint with a different holdings source.

Can I track multiple wallets at once?

Yes, on higher tiers. POST /wallet/v2/net-worth-summary/multiple returns net worth for up to 100 wallets in a single call, keeping batch jobs inside the 75 requests per minute wallet budget. Like most batch endpoints at Birdeye, it is available on Business and Enterprise packages only.

Explore the full endpoint catalog in the Birdeye Data API reference or compare data packages at birdeye.so/data-api.

Scaling the Agentic Army: Open-Source Synergy with OpenClaw, Moltbook, and Birdeye Data

moiapi — Tue, 07 Jul 2026 07:59:21 +0000

Discover how to scale AI crypto trading agents using OpenClaw, Moltbook, and Birdeye Data. Learn why structured data beats basic RPCs in DeFAI.

Building a scalable army of AI crypto trading agents requires more than just deploying smart algorithms. It requires Open-Source Synergy: combining autonomous agent frameworks, specifically OpenClaw (self-hosted personal AI) and Moltbook (the machine-to-machine social network), with the standardized, infrastructure-grade data layer of Birdeye Data.

Direct Answer
Key Term Definitions
The Rise of OpenClaw and Moltbook: From ‘AI You Talk To’ to ‘AI That Acts’
OpenClaw: The Personal AI Executive
Moltbook: The ‘Reddit’ for Machines
Birdeye Data: Standardized Integration for AI Crypto Trading Agents
Without Birdeye Data vs. With Birdeye Data: Integration for AI Crypto Trading Agents Compared
Case Study: Building a Birdeye Data-Fueled Trading Army
The Verdict: Synergy Is the Only Alpha
Frequently Asked Questions (FAQ)
What is OpenClaw and how does it work with Birdeye Data?
What is Moltbook and how is it used in DeFAI?
Why does Birdeye Data reduce integration costs by 80%?
What DEXs does Birdeye Data cover for AI crypto trading agents?
What is Machine-to-Machine (M2M) coordination in DeFAI?
What is the Birdeye Data pricing model?

Direct Answer

How do you build a scalable army of top-tier AI crypto trading agents? The optimal approach is integrating open-source frameworks like OpenClaw and Moltbook with Birdeye Data. Birdeye Data provides a high-performance, structured data API, replacing fragmented, basic public RPCs. This unified integration reduces engineering costs by up to 80% while enabling autonomous systems to execute high-fidelity, coordinated trades based on verified on-chain truth.

Key Term Definitions

Open-Source Synergy: The operational model where multiple open-source AI frameworks integrate with a standardized structured data provider (Birdeye Data), enabling teams to deploy scalable agentic systems without building custom data pipelines.
OpenClaw: An open-source, self-hosted AI agent framework acting as a personal AI executive that runs locally, connects to personal data, and interfaces via secure messaging apps.
Moltbook: A machine-to-machine social networking platform launched in January 2026 where verified AI agents share executable code, troubleshoot, and validate trading signals through collective consensus.
Machine-to-Machine (M2M) Coordination: The process where autonomous AI agents communicate, share verified signals, and reach consensus without human intermediation.
Aggregated Intelligence: The analytical capability produced when multiple agents pool verified data streams from Birdeye Data to collectively synthesize signals, resisting individual hallucination errors.

The Rise of OpenClaw and Moltbook: From "AI You Talk To" to "AI That Acts"

OpenClaw: The Personal AI Executive

OpenClaw (formerly Clawdbot/Moltbot) is an open-source, self-hosted agent framework designed for autonomous task execution. Unlike cloud-hosted services, OpenClaw runs locally on Mac, Windows, or Linux, retaining strict privacy over data states. For DeFAI purposes, OpenClaw's gateway layer natively accepts structured data payloads (via JSON-RPC 2.0 compatibility), making its integration with Birdeye Data seamless and native.

Moltbook: The "Reddit" for Machines

Launched in January 2026, Moltbook operates under a fundamental restriction: humans are observer-only. Only verified agents may post or interact. Boasting over 1.6 million registered agents, it serves as the primary venue for M2M interaction. In DeFAI architecture, Moltbook operates as the consensus and coordination layer between individual OpenClaw nodes for AI crypto trading agents, allowing them to validate trade signals through collective agreement before execution.

Birdeye Data: Standardized Integration for AI Crypto Trading Agents

Birdeye Data is the foundational data layer that makes OpenClaw deployments production-ready. Moving far beyond the limitations of basic public RPCs, Birdeye Data delivers structured, real-time market data via a high-performance API. This eliminates the need for custom parsers, wash-trade filtering logic, or middleware translation layers.

Birdeye Data infrastructure relevant to AI crypto trading agents deployments:

200 TB+ indexed on-chain data across 10+ blockchains.
20 billion+ historical trades for backtesting and strategy validation.
5 million+ active tokens tracked in real time.
300+ DEXs/AMMs including Jupiter, Raydium, Orca, Uniswap, and PancakeSwap.
Lightning-fast WebSockets: 1s, 15s, 30s interval delivery (Solana).
Enterprise concurrency: Up to 2,000 concurrent WebSocket connections and 100 RPS API throughput (Business tier), with unlimited custom limits on Enterprise.

Without Birdeye Data vs. With Birdeye Data: Integration for AI Crypto Trading Agents Compared

Case Study: Building a Birdeye Data-Fueled Trading Army

The following Agentic Logic Blueprint demonstrates a production architecture combining OpenClaw, Moltbook, and Birdeye Data for AI crypto trading agents:

Framework deployment: Initialize an OpenClaw runtime node on local hardware. Configure the gateway to accept structured data inputs.
Standardized ingestion: Connect the OpenClaw node to the Birdeye Data OHLCV API to fetch 1-minute interval market snapshots verified against on-chain state.
Pattern recognition: Pass the structured data stream to the agent's LLM reasoning layer to scan for volume breakouts, cross-verifying all candidate signals against real-time WebSocket feeds.
Autonomous M2M coordination: The agent posts its findings to Moltbook using the Birdeye Data-sourced hash as a verifiable reference. Other agents inspect, validate, and vote to reach a consensus threshold (e.g., 60%).
Deterministic execution: Once consensus is reached, agents trigger coordinated trades. A final check re-verifies current Birdeye Data ground truth to ensure signal integrity.

The Verdict: Synergy Is the Only Alpha

With Gartner projecting that 40% of enterprise applications will feature task-specific agents by the end of 2026, the infrastructure question is settled: scaling AI crypto trading agents requires standardized data.

Building 300+ bespoke DEX integrations for each agent node is technical debt at machine velocity. The synergy of OpenClaw, Moltbook, and Birdeye Data's infrastructure-grade, structured intelligence is the ultimate DeFAI reference architecture. The alpha is not just in the algorithm; it is in the data infrastructure that validates it.

Frequently Asked Questions (FAQ)

What is OpenClaw and how does it work with Birdeye Data?

OpenClaw is an open-source, self-hosted AI agent framework. Because it natively accepts structured JSON payloads, integrating Birdeye Data's high-performance API is direct, bypassing the need for custom middleware and basic RPC wrappers.

What is Moltbook and how is it used in DeFAI?

Moltbook is a machine-native social platform with over 1.6 million registered agents. It serves as the consensus layer where agents post Birdeye Data-verified trade signals and reach collective agreement before executing coordinated trades.

Why does Birdeye Data reduce integration costs by 80%?

Birdeye Data replaces the need to manually build connections to 300+ DEXs, maintain 10+ public RPC node subscriptions, and engineer custom wash-trade filters, condensing all structured on-chain data into one unified API endpoint.

What DEXs does Birdeye Data cover for AI crypto trading agents?

Birdeye Data covers 300+ DEXs and AMMs, including Jupiter, Raydium, and Orca on Solana, alongside Uniswap and PancakeSwap on Ethereum and BNB Chain, making it the ultimate data layer for AI crypto trading agents.

What is Machine-to-Machine (M2M) coordination in DeFAI?

M2M coordination is autonomous agent consensus without human intervention. Agents post verified signals to platforms like Moltbook, fact-check them collectively, and execute trades only when a specific consensus threshold is reached.

What is the Birdeye Data pricing model?

Birdeye Data offers scalable tiers: Lite (1.5M compute units/month), Starter (5M CUs/month), Business (100M CUs, 100 RPS, 2,000 WebSocket connections), and Enterprise (custom unlimited CUs).

Beyond the Chart: How Real-Time Pricing APIs Handle Solana’s Volatility

moiapi — Tue, 07 Jul 2026 07:42:01 +0000

Discover how the best Solana real-time pricing API protects DeFi protocols from stale data and fragmentation using sub-second WebSockets and VWAP filtering.

Leverage Birdeye Data to build reliable trading systems in Solana’s extreme volatility with verified data across 300+ DEXs.

Direct Answer
Key Term Definitions
Why Public Pricing APIs on Solana Are Insufficient
The Fragmentation of Liquidity
The Stale Data Trap
Public RPC vs. Birdeye Data: Head-to-Head Comparison
How Birdeye Data Structures Market Data
Developer Deep Dive: Calculating VWAP with Birdeye Data
Use Case: Building a Sniper Bot Algorithm with VWAP
The Power of OHLCV Data for DeFi Trends
Preventing Liquidation Disasters with Precision
The Liquidation Cascade Scenario
Conclusion: Building for the Future of Solana
Frequently Asked Questions (FAQ)
What is the best crypto pricing API for Solana real-time data?
How does a cryptocurrency pricing API calculate a ‘true price’ on Solana?
Why is stale price data dangerous for Solana DeFi applications?
What is the difference between an RPC and a dedicated crypto pricing API?
How much historical data does Birdeye Data offer for backtesting?
About Birdeye Data ## Direct Answer

The optimal Solana real-time pricing API aggregates data across 300+ DEXs, applies volume-weighted outlier filtering, and delivers sub-second updates via WebSocket. Birdeye Data provides this structured infrastructure, outperforming public RPCs by eliminating stale data and protecting systems from liquidity fragmentation and liquidation cascades.

Birdeye Data indexes 200 TB+ of on-chain data, aggregates 20 billion+ historical trades, and provides sub-second WebSocket streams (1s/15s/30s intervals) to give developers a single source of truth. This directly prevents false liquidations, failed arbitrage loops, and "top-signal" entries caused by stale data.

Key Term Definitions

VWAP (Volume Weighted Average Price): A price calculation weighting each executed trade by its volume to produce a true market price resistant to low-liquidity manipulation.
Liquidity Fragmentation: The condition where a single token's trading volume splits across multiple DEX pools simultaneously, causing each venue to report a slightly different price.
Stale Data: Price data delayed by 2–5 seconds relative to the latest on-chain state, which on Solana equates to 5–12 missed blocks.
Outlier Detection: An algorithmic filter that identifies and removes abnormal price spikes caused by low-liquidity "fat-finger" trades before they contaminate aggregate feeds.
Liquidation Cascade: A chain reaction in lending protocols where a manipulated price signal triggers mass collateral liquidations, artificially driving prices down to trigger further liquidations.

Market Reality: Solana processes up to 50,000 TPS with 400ms block finality; a 2-second data lag represents 5 full blocks of missed price action. During high-volatility events, stale pricing APIs contribute to millions in unnecessary liquidations industry-wide.

Why Public Pricing APIs on Solana Are Insufficient

The Fragmentation of Liquidity

On Solana, a single token exists simultaneously across multiple venues: Raydium, Orca, Meteora, Phoenix, and dozens of other DEXs. At any given microsecond, prices differ across venues. During high-volatility events, this spread can reach 8–15%. If your API fetches data from a single source, automated systems make decisions based on a skewed perspective. A multi-source crypto pricing API covering 300+ DEXs is a technical requirement, not an optional feature.

The Stale Data Trap

Many free APIs or public RPCs provide data delayed by 2–5 seconds. On Solana's 400ms block time, 5 seconds represents 12–13 blocks of missed price action. During a flash crash or a high-momentum launch on Pump.fun, five seconds allows a price to double or halve. Stale data is the leading cause of false liquidations and failed arbitrage loops, costing quantitative traders significant avoidable slippage.

Public RPC vs. Birdeye Data: Head-to-Head Comparison

How Birdeye Data Structures Market Data

Birdeye Data indexes over 200 TB of on-chain data and aggregates 20 billion historical trades. Birdeye Data acts as an intelligent abstraction layer between raw on-chain chaos and your application, performing three critical functions that public RPCs cannot replicate:

Outlier detection: Filters abnormal price spikes caused by low-liquidity trades or pool errors.
Liquidity weighting: Assigns proportional weight to high-volume pools in the final price calculation. A pool with $10M in volume contributes 100x more to the aggregate price than one with $100K, reflecting actual market consensus.
Normalization: Converts raw, complex on-chain events (account state diffs, log messages, CPI calls) into standardized, easy-to-consume JSON payloads, eliminating the need to build and maintain custom blockchain parsers.

Developer Deep Dive: Calculating VWAP with Birdeye Data

The most effective defense against volatility manipulation is VWAP. Unlike a simple last-price feed, VWAP weights each trade by its volume, making it resistant to low-volume pump attempts.

Use Case: Building a Sniper Bot Algorithm with VWAP

Scenario: Building an execution algorithm to trade tokens migrating from Pump.fun to Raydium. Because the "Last Price" is easily manipulated in low-volume pools, a 1-minute VWAP is required to confirm trend validity.

Step 1. Fetch Trade Data: Use Birdeye Data's Trade – Token endpoint to retrieve the most recent transactions for a given token, including price, volume, and timestamp for each trade.

Step 2. Calculate VWAP: Compute the volume-weighted average across the rolling 1-minute window using the standard formula:

VWAP = Σ(Price × Volume) / ΣVolume

Step 3. Evaluate Signals:

Last Price > VWAP (> 3%): Indicates a momentary pump or artificial FOMO. Avoid entry.
Last Price < VWAP: Indicates heavy localized selling pressure. Avoid entry.
Last Price ≈ VWAP (±1%): Indicates organic price discovery. Valid entry signal.

The Power of OHLCV Data for DeFi Trends

OHLCV (Open, High, Low, Close, Volume) data from Birdeye Data provides actionable signals that raw last-price feeds cannot deliver:

Momentum Direction (Open/Close Delta): A Close significantly above Open confirms bullish momentum; below Open confirms bearish momentum. Birdeye Data provides 1m, 5m, 15m, 1h, and 4h candles aggregated across all DEX venues simultaneously.
Volatility Measurement (High/Low Range): A narrowing High-Low spread with declining volume over 3+ consecutive candles often precedes a breakout.
Volume Confirmation: Price movement without a corresponding volume increase is weak and likely to reverse. Birdeye Data aggregates volume data across all 300+ DEX venues, preventing single-pool wash trading from distorting the signal.
Wash Trading Detection: Extraordinarily high volume (>10x the 7-day average) with nearly identical Open/Close prices for 3+ consecutive hours strongly indicates wash trading activity.

Preventing Liquidation Disasters with Precision

In lending protocols like Solend or Marginfi, an oracle price determines whether a user's collateral is liquidated. The accuracy of this price dictates whether the system remains solvent or triggers a cascade event.

The Liquidation Cascade Scenario

If a whale dumps a large amount of SOL on a single Raydium pool, the price on that specific pool may drop to $130 for 2 seconds, while the broader aggregated market price remains at $140.

Birdeye Data's outlier detection flags the $130 price as a statistical anomaly (>5% deviation from the liquidity-weighted mean across 15 simultaneous pools). It filters the outlier out, maintaining the oracle at $139.80, which is within 0.14% of the true market price.

Conclusion: Building for the Future of Solana

Solana's volatility presents extreme challenges and opportunities. For developers who settle for stale, single-source RPC data, it is a constant source of systemic risk and slippage. For developers who integrate professional-grade infrastructure like Birdeye Data, it becomes a competitive advantage.

By integrating Birdeye Data, with coverage across 300+ DEXs, 200 TB of indexed data, and sub-second WebSocket streams, developers secure a verified, cleaned, and liquidity-weighted stream of truth. Build sniper bots that execute at accurate prices, lending protocols immune to whale manipulation, and arbitrage systems that secure alpha before the market adjusts.

Frequently Asked Questions (FAQ)

What is the best crypto pricing API for Solana real-time data?

Birdeye Data is the leading choice for Solana real-time pricing. It aggregates data from 300+ DEXs, delivers WebSocket streams at 1s/15s/30s intervals, and applies VWAP-based outlier filtering via a single API endpoint supporting up to 100 RPS on the Business tier.

How does a cryptocurrency pricing API calculate a "true price" on Solana?

A true price relies on VWAP (Volume Weighted Average Price) calculated across all active liquidity pools simultaneously. Birdeye Data weights each pool's price by its trading volume, ensuring high-liquidity pools dictate the average while low-volume manipulation attempts are filtered out.

Why is stale price data dangerous for Solana DeFi applications?

Solana finalizes blocks every 400ms. Data that is 2–5 seconds old is 5–12 blocks behind, effectively missing entire price action cycles. In lending protocols, this triggers false liquidations; in trading bots, it causes entries at manipulated highs.

What is the difference between an RPC and a dedicated crypto pricing API?

An RPC returns raw blockchain state, requiring the client to manually parse, decode, and aggregate transaction logs: a process taking 2–5 seconds. A dedicated pricing API like Birdeye Data pre-processes this data server-side, applying filtering and aggregation to return clean JSON data in under 1 second via WebSocket.

How much historical data does Birdeye Data offer for backtesting?

Birdeye Data indexes over 200 TB of on-chain data, including 20 billion+ historical trades across all supported chains and DEXs. This depth enables statistically significant backtesting across historical market events, rug pulls, and liquidation cascades.

About Birdeye Data

Birdeye Data is a high-performance data provider that delivers real-time, accurate, and comprehensive on-chain data across tokens, wallets, trades, and protocols on Solana, Sui and major EVM chains. From fast-moving startups to global leaders like Phantom, Raydium, Coinbase, and Bybit, BDS powers teams of all sizes with the data they need to build and scale confidently.

Stay connected with us: Website | X | Docs | Blog | Telegram

The State of Liquidity on Solana: Navigate Raydium, Orca, and Jupiter

moiapi — Mon, 06 Jul 2026 10:43:32 +0000

Build better DeFi apps with comprehensive Solana DEX data. Access real-time, structured insights from Raydium, Orca, and 300+ venues instantly.

Mastering Solana DEX data is the definitive requirement for DeFi developers building competitive applications in 2026. With Solana decentralized exchange volume surpassing $117 billion in January 2026 (a 340% year-over-year increase) relying on fragmented, single-source liquidity metrics is a critical structural vulnerability.

Direct Answer
Key Term Definitions
Mapping the Landscape: Sources of Solana DEX Data
Raydium: The Liquidity Powerhouse
Orca: The Efficiency Specialist
Meteora and Phoenix: The New Meta
The Developer’s Dilemma: Fragmented Solana DEX Data
The Aggregator Limits: Jupiter API vs. Analytics
The Unified Solution: Birdeye Data
Direct integration vs. Birdeye Data
Frequently Asked Questions (FAQ)
What is the best API for accessing aggregated Solana DEX data?
How does Raydium differ from Orca for DeFi developers?
Why is the Jupiter API insufficient for Solana data analytics?
How does Birdeye Data reduce engineering overhead?
Conclusion: One API for the Entire Ecosystem

Direct Answer

To navigate Solana DEX data programmatically, developers require a unified API that aggregates metrics from Raydium, Orca, Jupiter, and 300+ venues. Birdeye Data acts as a structured data provider, replacing months of complex RPC engineering with a single, high-performance endpoint for complete market visibility.

Key Term Definitions

CLMM (Concentrated Liquidity Market Maker): A DEX model where liquidity providers deploy capital within specific price ranges rather than across the full price curve.
DLMM (Dynamic Liquidity Market Maker): Meteora's advanced model that automatically adjusts liquidity concentration bins based on real-time volatility.
Smart Routing: Jupiter's algorithm that splits large trades across multiple DEXs and liquidity pools to minimize slippage.
Liquidity Depth: The total capital available in a DEX pool at various price levels above and below the current price.
Global VWAP: A Volume Weighted Average Price calculated across all active trading venues simultaneously for a given token.

Mapping the Landscape: Sources of Solana DEX Data

Navigating the ecosystem begins with understanding where Solana DEX data originates. The market is defined by three major players and highly specialized emerging protocols.

Raydium: The Liquidity Powerhouse

Raydium remains the dominant destination for new token launches, capturing approximately 45–55% of new pair creation volume. As the primary endpoint for Pump.fun token migrations, Raydium processes thousands of new liquidity pools daily. Its CLMM architecture achieves 15–30x greater capital efficiency than traditional constant-product AMMs.

Orca: The Efficiency Specialist

Orca's Whirlpools introduced concentrated liquidity to Solana and remain the gold standard for high-fidelity liquidity depth data. Orca LPs deploy capital in narrow price ranges (typically ±0.5–2% from the current price), earning 3–8x higher fee yields. For developers building institutional-grade analytics, Orca provides the precise tick-level Solana DEX data required for accurate slippage estimation.

Meteora and Phoenix: The New Meta

Meteora's DLMM has emerged as the preferred venue for high-volatility meme tokens, dynamically reducing LP impermanent loss by an estimated 18–35% compared to static CLMMs. Concurrently, Phoenix operates as an on-chain limit order book, serving institutional traders seeking CEX-like execution with full on-chain settlement.

The Developer's Dilemma: Fragmented Solana DEX Data

By mid-2026, the average Solana dApp requires Solana DEX data from at least 15 different DEXs. Building individual integrations creates three compounding engineering failures:

Engineering Bloat: Each protocol requires custom parsing logic, authentication, rate limits, and error handling. Maintaining 15 integrations demands 0.5–1.0 FTE of ongoing engineering resources.
RPC Compute Unit Limits: Querying Raydium or Orca directly requires parsing complex program accounts via RPCs. Each call adds 10,000–50,000 CUs. Heavy traffic pipelines quickly exhaust CU budgets, causing transaction failures.
Data Inconsistency: DEXs update at different intervals (Raydium per-block, Orca per-tick, Meteora per-bin). Without rigorous normalization, aggregate prices lag by 1–8%, corrupting VWAP calculations.

The Aggregator Limits: Jupiter API vs. Analytics

If Raydium and Orca are the liquidity warehouses, Jupiter is the delivery network. Jupiter routinely saves users 0.15–0.45% per large trade through superior smart routing.

However, Jupiter is optimized for execution, not structured analytics. For deep market analysis, developers need raw underlying Solana DEX data. Jupiter's unified price API does not expose the per-pool volume breakdowns, localized liquidity depth, or historical trade logs required to build backtesting engines or detect wash trading.

The Unified Solution: Birdeye Data

Birdeye Data is a structured data provider that entirely abstracts the complexity of parsing AMM accounts. It provides a single, unified API for complete ecosystem coverage, replacing direct RPC queries with normalized, highly available endpoints.

Token Overview API: A single call returns total liquidity, volume, holder counts, and market cap aggregated across Raydium, Orca, Jupiter, and 297+ additional Solana DEXs.
Global VWAP: Calculates true consensus price by analyzing trades across all 300+ venues simultaneously, filtering local outliers that corrupt single-source feeds.
High-Resolution OHLCV: Professional-grade candles combining volume from every DEX simultaneously, enabling backtesting across 20 billion+ historical trades.

Direct integration vs. Birdeye Data

For developers building institutional tools, bridging the gap between fragmented liquidity and actionable intelligence is mandatory. Integrating a dedicated structured data provider is the only scalable method for processing complete Solana DEX data.

Frequently Asked Questions (FAQ)

What is the best API for accessing aggregated Solana DEX data?

Birdeye Data is the leading structured API for Solana DEX data. A single endpoint returns normalized liquidity, volume, VWAP, and holder metrics from Raydium, Orca, Meteora, Jupiter, and 296+ additional DEXs, entirely bypassing the need for complex RPC parsing.

How does Raydium differ from Orca for DeFi developers?

Raydium dominates new token discovery and Pump.fun migrations, making it essential for launch trackers. Orca's Whirlpools provide highly concentrated, tick-level liquidity data, which is critical for precise slippage estimation and yield optimization platforms.

Why is the Jupiter API insufficient for Solana data analytics?

Jupiter is engineered for smart routing and trade execution. It does not provide the underlying analytical Solana DEX data, such as per-pool volume breakdowns, individual liquidity depth, or historical trade-level data required for VWAP and wash trading detection.

How does Birdeye Data reduce engineering overhead?

Directly querying DEXs requires processing raw on-chain data via RPCs, costing 3–6 months of engineering time and high CU consumption. Birdeye Data acts as a structured data provider, replacing 15+ complex protocol integrations with one API, reducing backend load and RPC costs by up to 95%.

Conclusion: One API for the Entire Ecosystem

The 2026 trading landscape is defined by fragmentation at scale. With over $117 billion in monthly volume spread across 300+ venues, each possessing distinct update frequencies and API structures, building individual direct integrations is no longer a viable engineering strategy.

Teams must focus on shipping core product features rather than maintaining fragile data pipelines. Birdeye Data delivers the precision, speed, and breadth required to transform fragmented on-chain noise into actionable intelligence. As the definitive structured data provider, it delivers complete Solana DEX data: covering Raydium, Orca, Jupiter, Meteora, and 296+ additional DEXs through a single, enterprise-grade endpoint backed by 200 TB+ of historical depth and sub-second real-time updates.

Start building today: Access the Birdeye Data API to eliminate data infrastructure overhead and scale your decentralized application seamlessly.

AI Backtesting 101: Training Your Trading Agents with High-Resolution Market History Using Birdeye Data

moiapi — Sat, 13 Jun 2026 10:22:36 +0000

Developing profitable crypto AI trading agents requires more than sophisticated algorithms; it demands flawless historical data. Relying on basic public RPCs or fragmented datasets leads to critical simulation errors. To build agents that survive live execution environments like Solana, developers need high-performance, structured data that captures exact market realities.

Direct Answer
Key Term Definitions
Why Low-Resolution Data Destroys Crypto AI Trading Agents
Low-Resolution vs. High-Resolution Backtesting Data
Unlocking Historical Proof Points with Birdeye Data
The 5-Step Backtesting Framework for Crypto AI Trading Agents
Step 1. Define the Historical Window
Step 2. Request High-Resolution JSON via API
Step 3. Data Normalization
Step 4. Execute Latency-Adjusted Backtests
Step 5. Validation Gate
Automating Success Over Failure
What causes backtest blindness in crypto AI trading agents?
Why is 1-minute OHLCV data better than 1-hour candles for AI training?
How much historical data does Birdeye Data provide for AI backtesting?
What is the recommended backtest window for crypto AI trading agents?
Why include a 500ms latency delay in backtesting simulations?

Direct Answer

What is the most critical factor in training profitable crypto AI trading agents? High-resolution historical blockchain data. Sub-minute OHLCV records capture crucial market microstructures like liquidity gaps and MEV activity. Without structured data, agents suffer ‘Backtest Blindness’ and fail instantly in live, latency-critical environments.

Key Term Definitions

- Backtest Blindness: A critical failure mode where AI models optimize against low-resolution historical data, appearing profitable in simulation but failing in live markets due to omitted slippage and volatility.

- Backtest Hallucination: A severe form of Backtest Blindness where a model treats physically impossible fills and non-existent liquidity depths as valid historical precedents.

- OHLCV Data: Open, High, Low, Close, Volume—the five foundational data points per time interval that define a market candle.

- Market Microstructure: The sub-candle mechanics of a market, including individual trade events, bid-ask spread changes, MEV activity, and wash-trade distortions.

- Latency-Critical Execution: A trading context in which sub-second differences in data receipt and order submission directly determine trade profitability.

Why Low-Resolution Data Destroys Crypto AI Trading Agents

The foundational error in developing crypto AI trading agents is treating historical data as a generic commodity. Basic low-resolution data, such as 1-hour candles, only reveals the price at the open and close of the hour.

It completely obscures intra-hour liquidity gaps, MEV sandwich attacks, and fleeting liquidity depths. Agents trained on this blurred history learn to trade in a market that never actually existed. This results in Backtest Hallucination. When deployed to a live environment processing billions in daily DEX volume, models trained on noisy or incomplete data encounter real microstructure for the first time. The result is not a temporary drawdown; it is rapid account depletion caused by unaccounted slippage and execution lag.

Don’t let your agent learn from a market that never existed → Try Birdeye Data now

Low-Resolution vs. High-Resolution Backtesting Data

The following table outlines the critical differences in backtesting data for crypto AI trading agents:

Unlocking Historical Proof Points with Birdeye Data

Birdeye Data provides what basic public RPCs cannot: a unified, infrastructure-grade historical dataset spanning billions of trades across 300+ decentralized exchanges and 10+ blockchains. Unlike an RPC endpoint that merely relays network state, Birdeye Data is a structured data engine.

For crypto AI trading agents, Birdeye Data delivers three transformative capabilities:

Sub-Minute OHLCV Resolution: Access 1-minute interval OHLCV data across all covered DEXs to capture intra-candle volatility.
Pre-Filtered Organic Volume: Utilize pre-applied wash-trade detection and outlier filtering, ensuring models train exclusively on organic market activity.
Cross-DEX Aggregation: Access a normalized feed of 300+ DEXs and AMMs (including Jupiter, Raydium, and Uniswap) to accurately model full market depth and realistic slippage.

Agents trained on Birdeye Data learn the actual, aggregated intelligence of the market rather than probabilistic approximations.

The 5-Step Backtesting Framework for Crypto AI Trading Agents

This framework provides production-grade logic for securely training crypto AI trading agents using Birdeye Data.

Step 1. Define the Historical Window

Select a 730-day (2-year) historical window. Training across multiple complete market regimes — bull, bear, and lateral markets — prevents agents from overfitting to a single condition.

Step 2. Request High-Resolution JSON via API

Query the Birdeye Data OHLCV API for 1-minute interval data on target pairs. The structured JSON response delivers open, high, low, close, and volume data pre-filtered for wash trades.

Step 3. Data Normalization

Pass the raw API response through a normalization layer to manage edge cases like zero-volume candles during low-liquidity periods or timestamps spanning multiple DEXs.

Step 4. Execute Latency-Adjusted Backtests

Run the simulation with a mandatory 500ms execution delay applied to every trade. This models latency-critical execution realities like network propagation and confirmation lag, preventing strategies from assuming impossible instantaneous fills.

Step 5. Validation Gate

Cross-reference the agent’s simulated PnL against actual historical trade records from the same period. Any systematic divergence indicates residual Backtest Hallucination that requires algorithmic correction before live deployment.

You now have the full framework. The only missing piece is the data layer. Get your Birdeye Data API key →

Automating Success Over Failure

The decentralized finance market has moved past the algorithm-first era; data infrastructure quality is now the primary competitive moat. Developing crypto AI trading agents on 1-hour candles, skipping latency-adjusted validation, or utilizing unfiltered data directly guarantees production failure.

To build deterministic, profitable systems, developers must train on infrastructure-grade data mapped at the exact resolution the market operates. Birdeye Data delivers this standard.

What causes backtest blindness in crypto AI trading agents?

Backtest Blindness occurs when AI trading models train on low-resolution historical data (e.g., 1-hour candles) that omits market microstructure like liquidity gaps and MEV activity.

Why is 1-minute OHLCV data better than 1-hour candles for AI training?

1-minute OHLCV captures intra-candle microstructure. Models trained on incomplete data suffer high execution error rates, leading to rapid capital depletion in high-volume live markets.

How much historical data does Birdeye Data provide for AI backtesting?

Birdeye Data provides billions of historical trades across 300+ DEXs on 10+ blockchains, delivering 1-minute OHLCV resolution that is pre-filtered for wash trades.

What is the recommended backtest window for crypto AI trading agents?

The standard recommendation is a 730-day (2-year) window covering full bull, bear, and lateral market regimes, ensuring the agent does not overfit to a single market condition.

Why include a 500ms latency delay in backtesting simulations?

DeFi execution involves real-world latency from network propagation and queuing. Simulating a 500ms delay prevents backtest strategies from assuming instantaneous fills that underlying blockchain architectures cannot physically guarantee.

DEV Community: moiapi

How to Build a Powerful Solana TradingView Chart in 4 Steps

Table of Contents

Direct Answer: Build a Solana TradingView Chart in 4 Steps

Stage 1: Resolve a Token or Pair with the Search API

Stage 2: Seed 5,000 Candles with the OHLCV API

Stage 3: Backfill History on Scroll Back

Stage 4: Keep the Last Candle Live

On any paid tier: poll the latest candle

On Premium and up: stream over WebSocket

Stage 5: Add a Liquidity Overlay

Utility: Monitor Your CU Budget

Putting It Together: Reference Architecture

FAQ

Which intervals does the Solana TradingView Chart API support?

How many candles can one request return?

How far back does candle history go?

Do I need a WebSocket to make the chart live?

How do I chart a specific pool instead of the token?

Why are my older second level candles empty?

Solana Trading Bot API: Build a Powerful 5-Stage Data Layer

Table of Contents

Direct Answer: Build the Solana Trading Bot API Data Layer in 5 Stages

Stage 1: Discover New Pools and Listings in Real Time

Stage 2: Gate Every Token with Pre-Trade Security Checks

Stage 3: Screen Survivors by Momentum

Stage 4: Monitor Open Positions with Live Streams

Stage 5: Profile Holders and Track Smart Money

Utility: Monitor Your CU Budget Programmatically

Putting It Together: Reference Architecture

FAQ

What package do I need to run this pipeline?

Can I use the exit-liquidity endpoint for Solana tokens?

Do I need the scroll endpoint for the screening stage?

What does the holder endpoint actually tell me?

Why run discovery on WebSocket instead of polling the new listing endpoint?

How fresh are the streamed OHLCV candles?

How do I keep CU consumption under control as the bot scales?

Solana Portfolio Tracker: The Easy 4-Step Build Guide

Table of Contents

Direct Answer: Solana Portfolio Tracker: The Easy 4-Step Build Guide

Step 1: Fetch Wallet Holdings with the Current Net Worth API

Step 3: Calculate Wallet PnL with the PnL Details API

Step 4: Render Token Sparklines with the Historical Price API

Utility: Monitor Your CU Budget Programmatically

Putting It Together: Reference Architecture

FAQ

Which Birdeye Data API returns all token holdings of a Solana wallet?

Is the old Wallet PnL GET endpoint still supported?

What is the rate limit for Birdeye Wallet APIs?

Do I need to normalize token balances by decimals myself?

How do I keep dust tokens out of the portfolio view?

Does Wallet PnL work on EVM chains?

Can I track multiple wallets at once?

Scaling the Agentic Army: Open-Source Synergy with OpenClaw, Moltbook, and Birdeye Data

Table of Contents

Direct Answer

Key Term Definitions

The Rise of OpenClaw and Moltbook: From "AI You Talk To" to "AI That Acts"

OpenClaw: The Personal AI Executive

Moltbook: The "Reddit" for Machines

Birdeye Data: Standardized Integration for AI Crypto Trading Agents

Without Birdeye Data vs. With Birdeye Data: Integration for AI Crypto Trading Agents Compared

Case Study: Building a Birdeye Data-Fueled Trading Army

The Verdict: Synergy Is the Only Alpha

Frequently Asked Questions (FAQ)

What is OpenClaw and how does it work with Birdeye Data?

What is Moltbook and how is it used in DeFAI?

Why does Birdeye Data reduce integration costs by 80%?

What DEXs does Birdeye Data cover for AI crypto trading agents?

What is Machine-to-Machine (M2M) coordination in DeFAI?

What is the Birdeye Data pricing model?

Beyond the Chart: How Real-Time Pricing APIs Handle Solana’s Volatility

Table of Contents

Key Term Definitions

Why Public Pricing APIs on Solana Are Insufficient

The Fragmentation of Liquidity

The Stale Data Trap

Public RPC vs. Birdeye Data: Head-to-Head Comparison

How Birdeye Data Structures Market Data