What does the NEAR Intents explorer show, and how do you query intent data programmatically?

What the NEAR Intents explorer actually shows

The NEAR Intents explorer is a dashboard over intent-based cross-chain activity. Its main panels are aggregate volume (all time, 24h, 7d, 30d), a list of top swaps, referral and affiliate leaderboards, and a live feed of individual intents. Each intent row typically exposes the asset and amount, sender and recipient addresses, the route or referral source, a status label, and a relative timestamp.

That makes it a verification and observability tool, not a trading terminal and not a chain explorer. It answers questions like: did this cross-chain swap settle, which solver or referral routed it, and how much volume moved through a given period. It does not replace a general NEAR block explorer for account balances, contract state, or raw transaction receipts.

• Aggregate volume panels for all time, 24h, 7d, and 30d
• Top swaps by notional size in the last 24 hours
• Referral and affiliate leaderboards by transaction count and volume
• Per-intent feed with asset, amount, sender, recipient, status, and timestamp
• Search by wallet address, deposit address, or transaction hash

Explorer UI, explorer API, or NEAR RPC: pick the right source

Most confusion around the NEAR Intents explorer comes from treating three different data sources as interchangeable. They are not. The explorer UI is for humans. The explorer API is a read-only historical interface for intent records. A NEAR RPC endpoint is the chain interface for account, block, and transaction state. Choosing the wrong one leads to brittle scrapers or missing data.

A practical rule: if the question is about an intent's lifecycle and routing, start with the explorer API. If the question is about on-chain state such as an account balance, a contract call result, or a block height, use NEAR RPC. If you need both in one product, you will run two data paths and join them in your own backend.

Decision guide: which source fits your workload

Use this short guide before you write code. It prevents the common mistake of building a backend against a UI that changes without notice, or of hammering an RPC endpoint for data that a historical API already returns.

• Verifying one swap by hand: use the explorer UI search by address or transaction hash.
• Building a dashboard of intent volume and statuses: use the explorer API and cache results.
• Checking an account balance or contract state: use NEAR RPC, not the explorer.
• Reconciling settlement across chains: join explorer API intent records with destination-chain RPC reads.
• Running alerts on stuck intents: poll the explorer API on a schedule and store state transitions.
• Needing predictable throughput for high-volume reads: use a managed or dedicated NEAR RPC endpoint rather than a shared public one.

Querying intent data without scraping the UI

The explorer exposes a read-only API for historical intent and transaction status data. Treat it as a data source with its own rate limits, pagination, and schema, and read its documentation before you depend on field names. The pattern below shows the shape of a typical request; replace the path and parameters with the ones documented by the API you are calling.

Keep the request logic in one adapter module so that schema changes are contained. Store the raw response alongside your normalized record so you can replay or re-derive fields later.

• Paginate explicitly and record the cursor or page token you last used.
• Handle non-200 responses and empty result sets as normal states, not exceptions.
• Persist the raw payload before normalizing so schema changes are recoverable.
• Log the request ID or timestamp for each poll to make incident review easier.

Reading NEAR chain state with JSON-RPC

When you need to confirm on-chain state, call a NEAR RPC endpoint. The example below uses the standard JSON-RPC shape for a block query. Use the endpoint URL provided by your RPC provider; for OnFinality, check the NEAR network page for the current endpoint rather than hard-coding a shared public URL.

Keep chain reads separate from intent reads in your code. A common production pattern is an intent poller that writes to a queue, and a chain reader that resolves on-chain references for each queued item.

• Use the block or chunk methods to confirm that a referenced block exists.
• Use account and view methods to read balances and contract state.
• Set explicit timeouts and retry with backoff on transient errors.
• Do not assume a successful intent status means the destination chain has finalized; verify on the destination chain when it matters.

Failure modes to expect when monitoring intents

Intent monitoring fails in predictable ways. The table below maps symptoms to likely causes and the next debugging step, so you can triage without guessing.

Production checklist before you ship an intent monitor

Before you put an intent monitor in front of users, confirm the operational basics. These items are cheap to check and expensive to discover in production.

• You have a documented data source for each field you display.
• Intent records and chain reads are stored separately and joined in your backend.
• Polling intervals respect the limits of the explorer API and your RPC provider.
• You have alerting on stuck intents and on RPC error rates.
• You have a fallback RPC endpoint or a managed provider for failover.
• You have reviewed RPC pricing so polling volume does not surprise you.
• You have checked supported RPC networks for current NEAR coverage before launch.

Frequently Asked Questions