SQD

io.github.subsquid-labsPublished by GitHub account subsquid-labsv0.8.5Updated Oct 24, 2026

Query 130+ SQD Portal datasets across blockchains, including native Tron transactions and events.

VerifiedStreamable HTTPWeb executableDatabasesFinanceData & Analytics

Overview

AI-generated overview

A read-only MCP server that answers blockchain questions from SQD Portal data across EVM, Solana, Bitcoin, Substrate, Hyperliquid and Tron.

What you can do
Discover networks, check indexing freshness and heads, and resolve token, contract, pool and coin names into query filters. Summarize recent activity, wallet fund flow and time-series activity across chains. Query raw EVM transactions, logs, traces, token transfers, contract deployments and contract activity, plus network-wide analytics and OHLC candles. Query Solana transactions and instructions, Bitcoin transactions, Substrate events and calls, Hyperliquid fills and candles, and Tron transactions and event logs. Run advanced debug queries for raw blocks, timestamp-to-block resolution and Hyperliquid replica commands.
When to use it
Useful when you want an assistant to investigate on-chain activity, wallets, contracts, tokens or DEX markets without writing Portal queries yourself. It suits exploratory analysis where coverage, freshness and pagination metadata matter, and it needs no account or API key.
Requirements
A remote endpoint at portal.sqd.dev over streamable HTTP, or a local install run with Node.js 22 or newer. No SQD account, API key or client credential is required. Network access to the hosted service is needed.
Before you install
Read-only: it queries indexed data and does not send transactions or move funds. Results can be partial, sampled, capped or paginated, and responses disclose this through coverage and freshness metadata, so check completeness before relying on an answer. The optional beta Explorer loads chain logo images from external CDN origins. Self-hosted HTTP deployments need host and origin allowlists configured for non-loopback binds.

Installation

In SourceWeft

  1. Open SQD in the dashboard and add it to a workspace.
  2. Enable the server for the chats that should use its tools.

Web executable via Streamable HTTP. Remote servers run from the web runtime once configured in a workspace.

Use with an agent

Paste this prompt into Claude Code, Codex, Cursor or another agent — or into SourceWeft chat. The agent reads this server's install guide, shows you its publisher, endpoint and sign-in, and adds it to your client once you agree. Keys never go into a command.

Read https://sourceweft.com/mcp/io.github.subsquid-labs%2Fportal-mcp-server/install.md and connect the MCP server it describes to my client. Before changing any config, show me its publisher, endpoint and sign-in method and wait for my OK. Never put an API key in a command or in a file I would commit; ask me where it should come from.

Read the install guide the agent follows

Other MCP clients

Add this to your client's mcpServers config.

{
  "mcpServers": {
    "sqd": {
      "type": "http",
      "url": "https://portal.sqd.dev/mcp"
    }
  }
}

README

SQD Portal MCP Server

[SQD Portal MCP server]

An MCP server that answers blockchain questions from SQD Portal data: transactions, logs, traces, token transfers, wallets, analytics, time series, and candles across EVM, Solana, Bitcoin, Substrate, Hyperliquid, and Tron networks, with an optional in-host Explorer.

The server does not index chains itself. It validates input, plans bounded Portal queries, and returns results with coverage, freshness, pagination, and evidence metadata so an assistant can say exactly what it saw. No SQD account, API key, or client credential is required.

It speaks the stateless MCP 2026-07-28 protocol over HTTP and stdio and keeps the SDK-managed legacy negotiation path for clients still rolling out that revision. Release notes are in CHANGELOG.md. See CONTRIBUTING.md to work on the code and SECURITY.md to report a vulnerability.

Current public surface

  • 28 public tools
  • 3 advanced/debug tools
  • public params use network
  • discovery filters use vm
  • no legacy tool aliases in v0.8.x

Raw query tools default to compact responses. Ask for response_format: "full" only when you need the larger payload.

Entity questions can use portal_resolve_entity first. It resolves EVM token symbols/addresses, EVM contract aliases, pool identifiers, protocol names, and Hyperliquid coin names into query-ready filters while keeping ambiguous matches explicit.

Token symbol resolution and token metadata come from open token-list data, not baked-in token address constants. Responses include explicit notices when token-list data is unavailable, stale, or unsupported for a network.

Wallet questions should start with portal_get_wallet_summary. It returns fund_flow by default, including inbound/outbound movement, asset flows, counterparties, largest observed movements, and next evidence pivots before raw-tool drill-down.

Tool groups

Discovery:

  • portal_list_networks
  • portal_get_network_info
  • portal_get_head
  • portal_resolve_entity

Cross-chain convenience:

  • portal_get_recent_activity
  • portal_get_wallet_summary
  • portal_get_time_series

EVM:

  • portal_evm_query_transactions
  • portal_evm_query_logs
  • portal_evm_query_traces
  • portal_evm_query_token_transfers
  • portal_evm_get_contract_deployment
  • portal_evm_get_contract_activity
  • portal_evm_get_analytics
  • portal_evm_get_ohlc

Solana:

  • portal_solana_query_transactions
  • portal_solana_query_instructions
  • portal_solana_get_analytics

Bitcoin:

  • portal_bitcoin_query_transactions
  • portal_bitcoin_get_analytics

Substrate:

  • portal_substrate_query_events
  • portal_substrate_query_calls
  • portal_substrate_get_analytics

Hyperliquid:

  • portal_hyperliquid_query_fills
  • portal_hyperliquid_get_analytics
  • portal_hyperliquid_get_ohlc

Tron:

  • portal_tron_query_transactions
  • portal_tron_query_logs

Advanced/debug:

  • portal_debug_query_blocks
  • portal_debug_resolve_time_to_block
  • portal_debug_hyperliquid_query_replica_commands

These groups are also the toolsets (discovery, convenience, evm, solana, bitcoin, substrate, hyperliquid, tron, debug). A deployment can trim the catalog with MCP_TOOLSETS or MCP_TOOLS, and an HTTP connection can narrow it further with ?toolsets= or an X-MCP-Toolsets header; see the HTTP deployment notes. With nothing configured the full 31-tool surface is served, and the hosted endpoint keeps that default.

Supported data

  • EVM networks indexed by Portal, including Base, Ethereum, Optimism, Arbitrum, Monad, Hyperliquid EVM, and many others
  • Tron native transactions (TRX transfers, TRC-10 transfers, contract calls with inline logs and internal transactions) and TVM event logs such as TRC-20 transfers, with Base58 or hex addresses, exact TRX amounts, and the parent transaction hash on every log; the bundled SQD plugin skill documents the raw Stream API for anything beyond that
  • Solana mainnet
  • Bitcoin mainnet
  • Hyperliquid fills and replica commands
  • Substrate networks indexed by Portal

Substrate support is currently historical only. It does not have a real-time tail.

Response shape

Most tools return the same envelope in MCP structuredContent and in a compact JSON text fallback for older clients. The envelope contains a normal result body plus shared metadata such as:

  • answer
  • display
  • next_steps
  • investigation
  • _freshness
  • _coverage
  • _pagination
  • _ordering

investigation is a compact evidence guide for agents: it identifies the primary result path, bounded window, useful pivot fields such as addresses or transaction hashes, follow-up filters, and limitations before a result is treated as complete. Successful material results also carry an _evidence receipt with canonical arguments, a deterministic digest, row reconciliation, source windows, and either exact or semantic replay semantics. Exact receipts pin their evidence window. Semantic receipts disclose that rerunning a moving relative window can return a newer snapshot.

When a response uses estimated, partial, sampled, capped, or paginated data, the top-level answer and metadata disclose it. _pagination.has_more is true exactly when next_cursor is present, and _coverage states whether the requested window was read through (window_complete) and whether the response holds every matching row (result_complete). Safe pagination follow-ups include executable tool-call metadata with explicit cursor arguments; suggestions that cannot be reconstructed safely are marked non-executable.

Chart-oriented tools also return chart and table descriptors so MCP clients or LLMs can render them without reverse-engineering the payload.

SQD Explorer (beta)

SQD Explorer is an MCP App that renders tool results inside hosts that support MCP Apps. It is in beta and off by default. A default deployment answers with structuredContent and compact JSON text only, and no tool result asks a host to open a UI. There are two ways to opt in:

  • One connection: add ?app=1 to the endpoint, for example https://portal.sqd.dev/mcp?app=1. Use this to try the beta without changing anything for other users.
  • Whole deployment: set MCP_APP_ENABLED=true. A connection can still override it in either direction, so ?app=0 opts a single client back out.

The app resource stays registered either way, so a host can read it directly without anyone opting in.

When it is enabled, compatible hosts receive an inline card sized to its content and a full-screen workspace for 21 data tools: metrics led by the primary number, multi-series and signed-value charts, price candles with linked volume and a fixed readout, ranked and timeline panels that show ten rows with a Show all control, evidence tables that page ten rows with search across every row, explorer links for addresses, hashes, and blocks, chain logos and names from SQD network metadata, continuation controls, current-session history, and JSON or CSV export through the host. Pointer and keyboard inspection expose exact plotted values. Missing buckets remain visible as gaps, identifiers stay unshortened, and any local row cap is separate from server completeness. Failed follow-ups keep the last good result under the error. The app is self-contained and does not use persistent browser storage; its only browser-side requests are chain logo images from cdn.subsquid.io and sqd.dev, the two origins declared in the resource CSP. Hosts without MCP App support receive the same structuredContent and compact JSON text fallback, so the underlying answer never depends on the UI. docs/explorer-design.md records the design rules the app follows.

Three MCP prompts provide reproducible starting points without adding tools:

  • investigate-wallet
  • investigate-contract
  • investigate-market

For a chart-first demo, ask: Show BTC price action and trading volume on Hyperliquid for the past hour, using five-minute candles. Explain whether the final candle is closed. The result opens the SQD Explorer with a candle chart, volume, an evidence table, requested and indexed time bounds, and a receipt. Replay the returned requested_window_start_timestamp and requested_window_end_exclusive as fixed from_timestamp and to_timestamp inputs when you need a stable verification run.

Try it in Claude

The hosted endpoint has the Explorer off, so a new user opts their own connection in:

  1. In claude.ai or Claude Desktop, open Settings → Connectors → Add custom connector, enter https://portal.sqd.dev/mcp?app=1, and choose no authentication. The ?app=1 turns the beta on for this connection only. On Claude Desktop you can instead install sqd.mcpb from the latest release and switch on its "SQD Explorer (beta)" setting.
  2. Start a new chat and enable the SQD connector for it.
  3. Ask a data question. Any of these lands on a tool that carries the Explorer:
    • What has this wallet been doing on Base lately? with an address (wallet summary)
    • Show me recent activity on Ethereum (recent activity)
    • Chart hourly transaction counts on Base for the last day (time series)

The result renders as an inline card instead of a block of text; open the card for the full-screen workspace. Only the 21 data tools carry the Explorer. A catalogue question such as Which networks do you support? calls portal_list_networks and answers in plain text, which is expected rather than a failure.

Install

bash
npm installnpm run build

Run

stdio:

bash
npm start

HTTP:

bash
npm run start:http

Developer discovery

The server exposes a structured tool-selection guide for client builders:

  • MCP resource sqd://tools returns grouped tool metadata, examples, starting points, and integration notes.
  • MCP resource sqd://tools/{name} returns the guide entry for one tool, for example sqd://tools/portal_get_time_series.

Tool and resource discovery stays on the MCP protocol itself. The server does not maintain a duplicate HTTP catalog.

Codex plugin

The Codex plugin wrapper lives in plugins/portal and defaults to the hosted MCP endpoint at https://portal.sqd.dev/mcp.

Install it from this repo-local marketplace:

bash
codex plugin marketplace add .codex plugin add portal@sqd

Open a new Codex thread after installing. First-use prompts include Hyperliquid BTC perp fills, recent Base transaction volume, and the latest USDC transfers on Base.

Claude Code plugin

The Claude Code plugin uses the same hosted MCP endpoint and the same public selector:

bash
claude plugin marketplace add subsquid-labs/portal-mcp-serverclaude plugin install portal@sqd

Open a new Claude Code session after installing so the SQD MCP tools are loaded.

Grok

Grok chat can use SQD as a custom connector:

  1. Open grok.com/connectors.
  2. Choose New Connector, then Custom.
  3. Enter https://portal.sqd.dev/mcp as the MCP server URL.
  4. Leave authentication unset.

Grok Build reads Claude Code plugins directly, so it uses the same package:

bash
grok plugin install --trust subsquid-labs/portal-mcp-server#plugins/portal

ChatGPT

In a workspace with custom MCP apps enabled, open Settings → Apps → Create, enter https://portal.sqd.dev/mcp, choose no authentication, scan the tools, and create the draft app. The server is read-only and does not require user credentials.

Claude Desktop

Download sqd.mcpb from the latest release and open it: Claude Desktop installs the bundle with one click and lists the 31 tools. The bundle carries the server, its production dependencies, and one optional setting, "SQD Explorer (beta)", which is off by default. It needs Node 22 or newer on the machine.

Manual fallback, from a local clone after npm run build, add an entry like this to claude_desktop_config.json:

json
{  "mcpServers": {    "SQD": {      "command": "node",      "args": ["/absolute/path/to/sqd-portal-mcp-server/dist/index.js"]    }  }}

Usage notes

  • If you do not know the exact network name, start with portal_list_networks.
  • If you need recent indexed state, use portal_get_network_info or portal_get_head first.
  • If the question is broad, start with portal_get_recent_activity, portal_get_wallet_summary, or portal_get_time_series before dropping to raw queries.
  • Time windows accept compact and natural wording such as 30m, past 30 minutes, in the past 1h, in last 38 mins, last hour, or 30 minutes ago.
  • Use portal_evm_get_ohlc and portal_hyperliquid_get_ohlc only when you actually need candle-shaped output.
  • For large or exploratory queries, prefer response_format: "compact" unless you need the full record shape.

HTTP Deployment Notes

HTTP mode exposes MCP at / and /mcp, liveness at /health, and readiness at /ready. The hosted service exposes the same versioned health response at https://portal.sqd.dev/mcp/health.

  • MCP and health endpoints do not require authentication.
  • Tool and resource discovery use the MCP protocol; retired /tools and /tools.json routes return 404.
  • Set MCP_CURSOR_SECRET on any deployment running more than one process, so a cursor one instance issues is accepted by the next. Unset, each process signs with its own random key, and a cursor stops working across a restart or a load-balanced hop.
  • /health reports version and commit, the git commit the image was built from, and every tool result repeats both in _server. Docker Hub tags: latest, X.Y.Z, and X.Y come only from a v* release tag; edge and sha-<commit> come from every main push. Pin a version tag in production.
  • /ready is 200 only after the dataset catalog has loaded once and the latest Portal probe succeeded within MCP_READY_MAX_AGE_MS; otherwise it is 503 with a reason and Retry-After. Point orchestrator readiness checks at /ready and liveness checks at /health. The Docker image's HEALTHCHECK uses /ready.
  • The server binds 127.0.0.1 unless MCP_BIND says otherwise, and every route checks the Host header (and Origin, when a browser sends one) against an allowlist, so a DNS-rebound page cannot reach a local instance. Loopback hosts and origins always pass; requests without Origin always pass the origin check. A non-loopback bind must set MCP_ALLOWED_HOSTS and MCP_ALLOWED_ORIGINS; if either is missing the server logs a startup error and serves without that check. The Docker image sets MCP_BIND=0.0.0.0, so set both variables in the deployment, or * behind a proxy that already validates them.
  • Every request is bounded: headers within MCP_HEADERS_TIMEOUT_MS, the whole request within MCP_REQUEST_TIMEOUT_MS, idle keep-alive within MCP_KEEP_ALIVE_TIMEOUT_MS, and MCP bodies above MCP_MAX_BODY_BYTES are refused with 413 before parsing (411 for a chunked body with no length).

Useful environment variables:

  • MCP_CURSOR_SECRET the key pagination cursors are signed with. Set it on any deployment running more than one process. Unset, each process signs with its own random key, so a cursor issued by one instance is rejected by the next and clients lose their place across a restart or a load-balanced hop. It is also what stops a caller minting a cursor for a window the tool would never have offered.
  • MCP_TOOLSETS comma-separated toolsets to serve (discovery, convenience, evm, solana, bitcoin, substrate, hyperliquid, tron, debug; all or default for everything). Unknown names are ignored with a startup error. Wins over MCP_TOOLS. Default: all nine, the full 31-tool catalog.
  • MCP_TOOLS comma-separated exact tool names to serve when MCP_TOOLSETS is unset.
  • Per connection, ?toolsets=evm on the endpoint URL or an X-MCP-Toolsets: evm header narrows the deployment's set for that connection only; it can never add a toolset. Prompts that reference a tool outside the active set are not offered. The active set is a bounded label (all, one toolset name, or custom) on mcp_tool_client_calls_total.
  • MCP_BIND interface to listen on, default 127.0.0.1 (0.0.0.0 in the Docker image)
  • MCP_ALLOWED_HOSTS comma-separated hostnames accepted in Host (port ignored) on top of loopback; * disables the check. Required for a non-loopback bind.
  • MCP_ALLOWED_ORIGINS comma-separated hostnames accepted in Origin on top of loopback; * disables the check. Required for a non-loopback bind.
  • MCP_REQUEST_TIMEOUT_MS, MCP_HEADERS_TIMEOUT_MS, MCP_KEEP_ALIVE_TIMEOUT_MS request timing bounds, defaults 120000, 30000, 65000
  • MCP_MAX_BODY_BYTES MCP request body cap, default 1048576
  • MCP_READY_PROBE_INTERVAL_MS and MCP_READY_MAX_AGE_MS readiness probe cadence and freshness, defaults 30000 and 90000
  • MCP_APP_ENABLED to offer the beta SQD Explorer to compatible hosts, default off. Accepts true or 1. Per-connection ?app=1 and ?app=0 override it.
  • MCP_TOOL_WEIGHT_BUDGET to bound the combined cost of active tool calls, default 32. Measured profiles allow up to 32 lookups, 4 raw or summary calls, or 2 analytics calls at once while queued work remains cancellation-aware.
  • MCP_TOOL_MAX_QUEUE to bound queued tool calls, default 64
  • MCP_TOOL_QUEUE_TIMEOUT_MS to bound tool admission wait time, default 5000
  • MCP_TOOL_CLIENT_WEIGHT_SHARE percent of the weight budget one caller (one connection, identified by a hashed address) may hold at once, default 50; never below the heaviest single tool so every tool stays schedulable. MCP_TOOL_CLIENT_MAX_QUEUE bounds one caller's queued calls, default 16. A caller over its share gets the retryable overloaded result with reason: client_share while others keep flowing.
  • MCP_TRUST_PROXY set to 1 (or to the number of proxies in front of the server) to key fairness on the address those proxies observed instead of the socket address. The header is read only when the immediate peer is itself a trusted proxy, and the hop is counted from the right of X-Forwarded-For, because a caller can write anything to the left of it. The address is hashed and never stored or labelled.
  • MCP_TRUSTED_PROXY_PREFIXES a comma-separated list of address prefixes that count as your proxies, matched against the start of the peer address (for example 203.0.113. or 2606:4700:). Setting it replaces the default rather than adding to it, so include loopback or your private range if a co-located proxy also reaches the server. With it unset, loopback and private ranges are trusted, which is where a co-located proxy sits; on a shared private network that means any host on that network can present a forwarded address, so name your proxies explicitly there.
  • MCP_SLOW_REQUEST_MS threshold for one JSON line on stderr per slow tool call with admission wait and execution timings and the bounded client family, default 5000.

Cost guardrails

Every scan bound in the server is compiled in and set per tool: a filtered trace scan stops at 5,000 blocks, a contract-deployment search at 1,000,000. Guardrails add a second ceiling above those that a deployment sets from the environment, so an endpoint under load can be turned down without a new image.

  • MCP_GUARDRAIL_MODE one of off (default), shadow, or enforce.
  • MCP_GUARDRAIL_<CLASS>_<LIMIT> sets one ceiling, where <CLASS> is LOOKUP, RAW_QUERY, SUMMARY, or ANALYTICS, and <LIMIT> is MAX_SCAN_BLOCKS, MAX_WINDOW_SECONDS, or MAX_UPSTREAM_BYTES. For example MCP_GUARDRAIL_RAW_QUERY_MAX_SCAN_BLOCKS=50000.

There are no numeric defaults. A class with nothing set has no extra ceiling, so off and enforce with nothing configured are the same server. The only way a guardrail changes behaviour is if you set a number.

shadow evaluates every ceiling and records what enforcing would have done, without changing a single response. enforce acts:

  • A scan over its ceiling stops at the ceiling and reports what it covered through the same partial-coverage path a scan that hits its compiled bound already uses, so _coverage.result_complete becomes false and the response names the blocks it searched. It never claims a complete answer it did not get.
  • A query window over its ceiling is refused before anything is fetched, with the cap named in the error and the next steps, because there is no partial result to return for a request that was never allowed to start.

Four counters, all with bounded labels: mcp_guardrail_admitted_total{class}, mcp_guardrail_would_block_total{class,limit}, mcp_guardrail_blocked_total{class,limit}, and mcp_guardrail_fail_open_total{reason}.

Recommended rollout. Set the ceilings you are considering and run shadow for a week. Read mcp_guardrail_would_block_total: it is exactly the set of real requests the ceiling would have cut. If that set is larger than you expected, the ceiling is wrong, not the traffic. Move to enforce once it is the size you intended.

Traces

Metrics say how often and how long; a trace says where the time went inside one call. Traces are off unless you set OTEL_EXPORTER_OTLP_ENDPOINT. With it unset nothing here is imported, allocated, or sent, and the OpenTelemetry packages need not be installed at all.

The SDK is not a dependency of this package. It and its exporter pull about 74 packages against a published tarball of roughly 3.4MB, and almost nobody running this over stdio wants any of it, so they are declared as optional peers. To turn traces on, install them alongside the server and point it at your collector:

bash
npm i @opentelemetry/sdk-node @opentelemetry/exporter-trace-otlp-http
bash
OTEL_EXPORTER_OTLP_ENDPOINT=http://collector:4318

One tool call is one tree:

mcp.request                       (HTTP only: method, transport)└─ tools/call portal_evm_query_logs   ├─ mcp.admission               (the wait for a slot)   ├─ portal.fetch                (one per attempt: dataset, status, bytes, resend count)   ├─ portal.fetch   └─ mcp.format_result           (hashing the answer for the evidence receipt)

OTEL_* variables are read by the OpenTelemetry SDK itself, so sampling, headers, batching, and protocol are configured the standard way. The rest:

  • A traceparent on the HTTP request, or in the tool call's _meta, makes the call part of the caller's trace rather than starting a new one. The _meta value wins, because it is the more specific claim about which turn this call belongs to.
  • Each Portal request carries a traceparent naming its own fetch span, so a Portal-side trace can join this one. Nothing is added when tracing is off.
  • The JSON log lines carry trace_id and span_id while tracing is on, so a log event and its span can be looked up from each other.
  • /health reports whether tracing is configured, whether it started, and whether argument capture is on.

Span attributes carry no arguments, addresses, hashes, cursors, or free text. They are the tool name, its work class, the dataset, bounded counts, and a bounded outcome. A span leaves the process for a collector the query itself never reaches, so the rule is the one the metric labels follow, and stricter than the logs, which at least stay on your own stderr. MCP_OTEL_INCLUDE_ARGS=1 adds the raw tool arguments to the tool span. It is off by default and unsafe for production: a tool argument is routinely a wallet address, and often a user's own words.

Tests

npm run test:offline builds, lints, typechecks, runs the unit tests, and runs every suite that needs no Portal access. npm run test:live runs the Portal-backed suites. RELEASE_ASSURANCE.md summarises what a release verifies, and scripts/README.md lists every suite.

License

MIT

Source: README.md at commit c19292d

Tools

31

portal_list_networks

Find blockchain networks

Find the right network or chain name to use across EVM, Solana, Bitcoin, Substrate, and Hyperliquid. COMMON USER ASKS: - Find Base-like networks - Show Solana mainnets - Show Substrate mainnets FIRST CHOICE FOR: - finding the correct network before any other query WHEN TO USE: - You are not sure which network name, chain name, or alias to use. - You want to filter networks by VM family, network type, or real-time availability. DON'T USE: - You already know the exact network and want live data from that network. EXAMPLES: - Find Base-like networks: {"query":"base","limit":10} - Show Solana mainnets: {"vm":"solana","network_type":"mainnet"} - Show Substrate mainnets: {"vm":"substrate","network_type":"mainnet"}

Parametersvmlimitquerycursornetwork_typereal_time_only

portal_get_network_info

Check network status

Answer "is this network caught up?" with indexing freshness, lag, heads, and available tables. COMMON USER ASKS: - Is Base caught up? FIRST CHOICE FOR: - checking indexing head, lag, tables, and capabilities for one network WHEN TO USE: - You want to know whether a network is indexed, fresh, caught up, or behind before querying. - You need chain family, real-time status, or available tables for a network. DON'T USE: - You only need the latest block or slot number. EXAMPLES: - Is Base caught up?: {"network":"base-mainnet"}

Parametersnetworkrequired

portal_get_head

Get the latest block

Get just the latest indexed head block or slot for a network. COMMON USER ASKS: - Latest head - Finalized head FIRST CHOICE FOR: - getting the current indexed head before building a manual block range WHEN TO USE: - You only need the current block or slot number. - You need the current head before building a raw block-range query. DON'T USE: - You want to know if the network is caught up, behind, fresh, or what tables are available. EXAMPLES: - Latest head: {"network":"base-mainnet"} - Finalized head: {"network":"ethereum-mainnet","type":"finalized"}

Parameterstypenetworkrequired

portal_resolve_entity

Find a token or contract

Resolve user-facing blockchain entities into query-ready identifiers, with ambiguity kept explicit. COMMON USER ASKS: - Resolve USDC on Base - Resolve WETH on Ethereum - Resolve BAYC contract FIRST CHOICE FOR: - resolving a token symbol like USDC to token contract addresses - resolving EVM contract aliases, protocol names, pool identifiers, or Hyperliquid coin names before querying - checking which token-list addresses a symbol maps to before querying logs or transfers - turning a user-friendly token name into deterministic EVM filters WHEN TO USE: - The user names a token symbol such as USDC, WETH, DAI, or PEPE and you need contract addresses before querying raw data. - The user names a well-known EVM contract, protocol, pool identifier, or Hyperliquid ticker and you need a deterministic follow-up filter. - You need to disambiguate bridged token variants on an EVM network. - You want a source-backed token address rather than relying on memory or hardcoded constants. DON'T USE: - You already have the exact address, pool id, protocol slug, or coin filter and can pass it directly. EXAMPLES: - Resolve USDC on Base: {"network":"base-mainnet","kind":"token","query":"USDC","limit":10} - Resolve WETH on Ethereum: {"network":"ethereum-mainnet","kind":"token","query":"WETH","limit":5} - Resolve BAYC contract: {"network":"ethereum-mainnet","kind":"contract","query":"bored apes"} - Resolve Hyperliquid coin: {"kind":"hyperliquid_coin","query":"bitcoin"}

Parameterskindlimitqueryrequirednetwork

portal_get_recent_activity

View recent blockchain activity

Get a simple recent-activity feed across EVM, Solana, Bitcoin, or Hyperliquid with chronological paging and investigation pivots. COMMON USER ASKS: - Recent activity on Base - Recent Hyperliquid fills FIRST CHOICE FOR: - recent activity on any supported network without manual block math - questions like "what has been happening on Base lately?" - first-pass incident triage when the user asks what happened recently on a network WHEN TO USE: - You want a quick recent-activity feed for a network. - You want to ask what has been happening lately on a network and see the newest activity first. - You want the simplest starting point before reaching for raw VM-specific query tools. - You are investigating an incident and need a bounded, recent evidence timeline before narrowing to wallets, transfers, logs, or fills. DON'T USE: - You need raw logs, instructions, or chain-specific fields that only raw query tools return. - You want a chart over time rather than a recent feed. EXAMPLES: - Recent activity on Base: {"network":"base-mainnet","timeframe":"1h","limit":10} - Recent Hyperliquid fills: {"network":"hyperliquid-fills","timeframe":"1h","limit":10}

Parameterslimitcursornetworktimeframeto_addressesto_timestampfrom_addressesfrom_timestamp

portal_get_wallet_summary

Review wallet activity

Summarize wallet activity and fund flow with shared overview, asset movement, counterparties, evidence pivots, and follow-up filters across supported networks. COMMON USER ASKS: - EVM wallet fund-flow triage - Solana wallet activity and fee flow FIRST CHOICE FOR: - one-call wallet analysis across supported VMs - suspicious wallet triage, fund-flow direction, counterparties, and next evidence pivots before drilling into raw records WHEN TO USE: - You want a single high-level answer about what one wallet has been doing and where value appears to move. - You want inbound/outbound flow, activity and asset-movement counterparties, largest movements within each asset, and exact next pivots before drilling into raw transactions or fills. - The user asks to investigate a suspicious wallet, stolen-funds path, exploit counterparty, or incident address. DON'T USE: - You need every raw record with full chain-specific fields and no summarization. EXAMPLES: - EVM wallet fund-flow triage: {"network":"base-mainnet","address":"0xabc...","timeframe":"24h"} - Solana wallet activity and fee flow: {"network":"solana-mainnet","address":"Vote111...","timeframe":"6h"}

Parametersmodecursoraddressnetworktimeframeinclude_nftsto_timestampfrom_timestampinclude_tokenslimit_per_typeresponse_format

portal_get_time_series

Chart blockchain activity

Build simple activity charts and other time-series views across supported VMs, including compare-previous windows and grouped EVM contract trends. COMMON USER ASKS: - Base transactions per 15m bucket - Compare two periods FIRST CHOICE FOR: - activity over time, compare-current-vs-previous, grouped trends, and simple activity charts WHEN TO USE: - You want chart-ready metric buckets over time. - You want a simple activity chart for a network, defaulting to a 6h interactive window unless a longer window is explicitly requested. - You want to compare the current period to the previous period. DON'T USE: - You need raw record lists instead of aggregated buckets. - You need DEX pool candles or OHLC output. EXAMPLES: - Base transactions per 15m bucket: {"network":"base-mainnet","metric":"transaction_count","duration":"6h","interval":"15m"} - Compare two periods: {"network":"solana-mainnet","metric":"transaction_count","duration":"1h","interval":"5m","compare_previous":true}

Parametersmodemetricrequiredaddressnetworkrequireddurationgroup_byintervalrequiredgroup_limitto_timestampfrom_timestampcompare_previous

portal_evm_query_logs

Find smart contract events

Query raw EVM logs with address/topic filters, common event aliases, earliest/latest scanning, and optional inline decoding. COMMON USER ASKS: - Recent USDC Transfer logs - First recent USDC Transfer log - Latest ERC721/pass mint ID and tx hash FIRST CHOICE FOR: - NFT or ERC721 mint lookups such as latest pass minted, token ID, and mint transaction hash - contract event questions where the user needs exact event evidence rather than wallet or transaction summaries WHEN TO USE: - You need event logs filtered by contract or topic signature. - You want decoded log hints while still keeping the raw log shape available. - You want the first or last matching event in a bounded block/time window. - You want common event names such as transfer, approval, swap, mint, or burn instead of remembering topic0 hashes. - You need the latest ERC721/pass mint in a bounded deployment/recent window: filter Transfer events with topic1 as the zero address, use scan_order=latest, limit=1, and decode=true to expose decoded_log.decoded.token_id plus transaction_hash. DON'T USE: - You only want token transfers, which are easier with the token-transfer tool. EXAMPLES: - Recent USDC Transfer logs: {"network":"base-mainnet","timeframe":"1h","token_symbols":["USDC"],"event":"transfer","limit":20} - First recent USDC Transfer log: {"network":"base-mainnet","timeframe":"1h","token_symbols":["USDC"],"event":"transfer","scan_order":"earliest","limit":1} - Latest ERC721/pass mint ID and tx hash: {"network":"base-mainnet","from_block":46020000,"to_block":46100000,"addresses":["0xE4E70FdF2Fc1147a7f35c4c5de88E6BeA63eeAfA"],"event":"transfer","topic1":["0x0000000000000000000000000000000000000000000000000000000000000000"],"scan_order":"latest","decode":true,"include_transaction":true,"limit":1} - Decode logs inline: {"network":"ethereum-mainnet","timeframe":"1h","topic0":["0xddf252ad1be2c89b69c2b068fc378daa952ba7f163c4a11628f55a4df523b3ef"],"decode":true,"limit":10}

Parameterseventlimitcursordecodetopic0topic1topic2topic3networkto_blockaddressestimeframe+13 more

portal_evm_query_transactions

Find Ethereum and Base transactions

Query raw EVM transactions with optional logs, traces, state-diff context, and evidence pivots for transaction-level investigations. COMMON USER ASKS: - Recent Base transactions - Filter by sender - First EIP-2930 transaction from Berlin fork WHEN TO USE: - You need raw transaction records on an EVM network. - You want chain-specific transaction fields or include flags that convenience tools do not expose. - You need exact transaction evidence for an investigation, including sender, receiver, transaction hash, logs, traces, or failed calls. - You need to find the first transaction matching a raw field condition such as transaction type 0x1 from a known block. - You need top-N raw transactions ranked by value, gas used, or effective gas price. - You need top senders or receivers from a bounded transaction window. - You want common method names such as transfer, approve, deposit, or withdraw instead of remembering sighashes. - You want calls to a token contract by symbol, such as transfer calls to USDC, without hardcoding token addresses. DON'T USE: - You only need a quick recent feed or wallet-level summary. EXAMPLES: - Recent Base transactions: {"network":"base-mainnet","timeframe":"1h","limit":20} - Filter by sender: {"network":"ethereum-mainnet","timeframe":"6h","from_addresses":["0xabc..."],"limit":20} - First EIP-2930 transaction from Berlin fork: {"network":"ethereum-mainnet","from_block":12244000,"transaction_type":"0x1","scan_order":"earliest","limit":1,"field_preset":"minimal"} - Largest recent calls to a resolved token contract: {"network":"base-mainnet","timeframe":"1h","to_token_symbols":["USDC"],"method":"transfer","order_by":"gas_used_desc","limit":5} - Top senders by transaction count: {"network":"base-mainnet","timeframe":"1h","aggregate_by":"sender","aggregate_metric":"count","limit":10}

Parameterslimitcursormethodnetworksighashorder_byto_blocktimeframefrom_blocklast_noncescan_orderfirst_nonce+23 more

portal_evm_query_traces

Find internal calls and contract creations

Query raw EVM traces: internal calls, contract creations, self-destructs, and block rewards, filtered by caller, callee, method, deployer, or one transaction, with the parent transaction hash on every row. COMMON USER ASKS: - Internal calls of one transaction - Recent internal calls into a contract - Contracts deployed by an address FIRST CHOICE FOR: - what a transaction called internally, including value moved by internal calls - contracts deployed by an address, or the internal call tree behind an incident WHEN TO USE: - You need the internal calls of a transaction: which contracts it called, with what selector and value, and which calls failed. - You want contracts created by a deployer or the creation trace of a contract. - You are tracing an exploit or incident below the top-level transaction and log surface. - You want internal ETH transfers between contracts that emit no event. DON'T USE: - You only need top-level transactions or event logs; those tools are cheaper. - You need storage changes; state diffs are not exposed by this tool. EXAMPLES: - Internal calls of one transaction: {"network":"ethereum-mainnet","from_block":12244145,"to_block":12244145,"transaction_hash":"0x851bad0415758075a1eb86776749c829b866d43179c57c3e4a4b9359a0358231","limit":25} - Recent internal calls into a contract: {"network":"base-mainnet","timeframe":"10m","type":["call"],"call_to":["0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913"],"method":"transfer","limit":20} - Contracts deployed by an address: {"network":"base-mainnet","timeframe":"24h","type":["create"],"create_from":["0x4200000000000000000000000000000000000006"],"limit":10}

Parameterstypelimitcursormethodcall_tonetworkto_blockcall_fromtimeframefrom_blockscan_ordercreate_from+11 more

portal_evm_query_token_transfers

Find token transfers

Query token-transfer activity on EVM without needing to remember Transfer event signatures. Best for "did token X move?" and asset-tracing questions. COMMON USER ASKS: - Recent USDC transfers - First recent USDC transfer WHEN TO USE: - You want ERC-20 style transfer activity filtered by token, sender, or recipient. - You want the fastest answer to a token movement question like "did USDC move?". - You are tracing suspicious, stolen, bridged, or exploit-related token movement and need sender/recipient/transaction pivots. - You want the easiest raw transfer query on an EVM network. - You need the first matching transfer in a bounded window without typing the Transfer topic hash. DON'T USE: - You need arbitrary event logs beyond token transfers. EXAMPLES: - Recent USDC transfers: {"network":"base-mainnet","timeframe":"1h","token_symbols":["USDC"],"limit":20} - First recent USDC transfer: {"network":"base-mainnet","timeframe":"1h","token_symbols":["USDC"],"scan_order":"earliest","limit":1}

Parameterslimitcursornetworkto_blocktimeframefrom_blockscan_orderto_addressesto_timestamptoken_symbolsfrom_addressesfrom_timestamp+3 more

portal_evm_get_contract_deployment

Find a contract deployment

Locate the create trace and parent transaction that deployed a specific EVM contract address within a bounded window. COMMON USER ASKS: - Find BAYC deployment - Find recent deployment - Find deployment from known range FIRST CHOICE FOR: - who deployed this EVM contract - when was this contract deployed - what deployment transaction created this contract WHEN TO USE: - You need the deployer, deployment block, deployment timestamp, or deployment transaction for an EVM contract. - You can provide a starting block/time window, a contract address, or a supported well-known contract alias such as BAYC/Bored Apes. - You want a deployment lookup instead of general contract activity. DON'T USE: - You need all activity for a contract after deployment. - The contract is old and no block/time hint is available; provide from_block or from_timestamp first. EXAMPLES: - Find BAYC deployment: {"network":"ethereum-mainnet","contract":"bored apes","from_block":12000000,"to_block":13000000,"scan_order":"earliest"} - Find recent deployment: {"network":"base-mainnet","contract_address":"0xabc...","search_depth_blocks":100000} - Find deployment from known range: {"network":"ethereum-mainnet","contract_address":"0xabc...","from_block":17000000,"to_block":17100000,"scan_order":"earliest"}

Parametersnetworkrequiredcontractto_blocktimeframefrom_blockscan_orderto_timestampfrom_timestampmax_scan_blockscontract_addresssearch_depth_blocks

portal_evm_get_contract_activity

Review smart contract activity

Summarize what one specific contract has been doing lately, including recent interactions, unique callers, and optional event activity. COMMON USER ASKS: - Contract activity snapshot FIRST CHOICE FOR: - what one specific contract has been doing lately on an EVM network WHEN TO USE: - You want to ask "what has this contract been doing?" and get a contract-level answer. - You want a contract-centric activity summary instead of raw records. - You need top callers and interaction volume for one contract. DON'T USE: - You need the underlying raw logs or transactions. - You want general recent network activity without naming one contract. EXAMPLES: - Contract activity snapshot: {"network":"base-mainnet","contract_address":"0xabc...","timeframe":"24h"}

Parametersmodenetworkrequiredtimeframeto_timestampfrom_timestampinclude_eventscontract_addressrequired

portal_evm_get_analytics

Analyze Ethereum and Base activity

Get the big picture for network-wide EVM activity with ranked contracts and compact overview metrics. COMMON USER ASKS: - Top contracts on Base FIRST CHOICE FOR: - the big picture for activity on an EVM network like Base or Optimism WHEN TO USE: - You want the big picture for activity on an EVM network. - You want the most active contracts on an EVM network. - You want an analytics-style network overview instead of a raw record list. DON'T USE: - You need chart buckets over time rather than ranked entities. EXAMPLES: - Top contracts on Base: {"network":"base-mainnet","timeframe":"1h","limit":10}

Parametersmodelimitcursornetworktimeframenum_blocksto_timestampfrom_timestampinclude_details

portal_evm_get_ohlc

Chart token price history

Build chart-ready EVM OHLC candles plus a recent trade tape from supported DEX event sources, including Uniswap v2-style swaps, Uniswap v3/v4, and Aerodrome Slipstream. COMMON USER ASKS: - Base Uniswap v2-style swap candles - Base Uniswap candles - Base Uniswap v4 candles WHEN TO USE: - You need OHLC candles for supported EVM event-derived price sources. - You want a candle chart and recent trades instead of scalar time-series buckets. - You want a Dexscreener-style pool chart with hover-ready candle metadata and a trade tape. DON'T USE: - You only need counts or scalar metrics over time. - You want a simple activity chart for a network rather than pool candles. EXAMPLES: - Base Uniswap v2-style swap candles: {"network":"base-mainnet","source":"uniswap_v2_swap","pool_address":"0x<pool-address>","duration":"1h","interval":"5m","price_in":"auto","include_recent_trades":true} - Base Uniswap candles: {"network":"base-mainnet","source":"uniswap_v3_swap","pool_address":"0x<pool-address>","duration":"1h","interval":"5m","price_in":"auto"} - Base Uniswap v4 candles: {"network":"base-mainnet","source":"uniswap_v4_swap","pool_id":"0x<pool-id>","duration":"1h","interval":"5m","price_in":"auto","include_recent_trades":true} - Base Aerodrome Slipstream candles: {"network":"base-mainnet","source":"aerodrome_slipstream_swap","pool_address":"0x<pool-address>","duration":"1h","interval":"5m","price_in":"token1"}

Parametersfeemodecursorsourcenetworkpool_iddurationintervalprice_inbase_tokenpool_addresstick_spacing+12 more

portal_solana_query_instructions

Find Solana program activity

Query raw Solana instructions with program and account filters. COMMON USER ASKS: - Token Program instructions WHEN TO USE: - You need program-level or account-level instruction activity. - You want to inspect Token Program, Jupiter, System Program, or Anchor discriminator activity. DON'T USE: - You only need transaction-level activity and not individual instructions. EXAMPLES: - Token Program instructions: {"network":"solana-mainnet","timeframe":"1h","program_id":["TokenkegQfeZyiNwAJbNbGKPFXCWuBvf9Ss623VQ5DA"],"limit":20}

Parametersa0a1a2a3a4a5a6a7a8a9d1d2+27 more

portal_solana_query_transactions

Find Solana transactions

Query raw Solana transactions with optional balances, rewards, logs, and instruction context. COMMON USER ASKS: - Recent Solana transactions - Filter by program WHEN TO USE: - You need raw Solana transaction records. - You want Solana-specific filters or include flags that convenience tools do not expose. DON'T USE: - You only want recent activity or a compact network summary. EXAMPLES: - Recent Solana transactions: {"network":"solana-mainnet","timeframe":"1h","limit":20} - Filter by program: {"network":"solana-mainnet","timeframe":"1h","program_id":["TokenkegQfeZyiNwAJbNbGKPFXCWuBvf9Ss623VQ5DA"],"limit":20}

Parameterslimitcursornetworkto_blockfee_payertimeframefrom_blockinclude_logsto_timestampfinalized_onlyfrom_timestampinclude_rewards+5 more

portal_solana_get_analytics

Analyze Solana activity

Get the big picture for Solana throughput, fees, wallet activity, and optional top-program usage. COMMON USER ASKS: - Solana network snapshot - Include top programs FIRST CHOICE FOR: - the big picture for Solana right now WHEN TO USE: - You want the big picture for Solana right now. - You want a network health snapshot for Solana. - You want throughput, fee, success-rate, or top-program analytics rather than raw records. DON'T USE: - You want chart buckets or raw transaction/instruction records. EXAMPLES: - Solana network snapshot: {"network":"solana-mainnet","timeframe":"1h"} - Include top programs: {"network":"solana-mainnet","timeframe":"1h","include_programs":true}

Parametersmodecursornetworktimeframeto_timestampprogram_limitfrom_timestampresponse_formatinclude_programsinclude_compute_units

portal_bitcoin_query_transactions

Find Bitcoin transactions

Query raw Bitcoin transactions and optionally attach inputs and outputs inline. COMMON USER ASKS: - Recent Bitcoin transactions - Attach inputs and outputs WHEN TO USE: - You need raw Bitcoin transaction records. - You want the UTXO envelope without switching to separate input/output tools. DON'T USE: - You only need a quick wallet or network summary. EXAMPLES: - Recent Bitcoin transactions: {"network":"bitcoin-mainnet","timeframe":"1h","limit":20} - Attach inputs and outputs: {"network":"bitcoin-mainnet","timeframe":"1h","include_inputs":true,"include_outputs":true,"limit":10}

Parameterslimitcursornetworkto_blocktimeframefrom_blockto_timestampfinalized_onlyfrom_timestampinclude_inputsinclude_outputsresponse_format

portal_bitcoin_get_analytics

Analyze Bitcoin activity

Get the big picture for Bitcoin block, fee, and address activity over a recent or explicit window. COMMON USER ASKS: - Bitcoin network snapshot FIRST CHOICE FOR: - the big picture for Bitcoin right now WHEN TO USE: - You want the big picture for Bitcoin right now. - You want a network-level Bitcoin snapshot. - You care about block cadence, fees, SegWit/Taproot adoption, or activity metrics. DON'T USE: - You need raw transactions rather than network analytics. EXAMPLES: - Bitcoin network snapshot: {"network":"bitcoin-mainnet","timeframe":"1h"}

Parametersmodenetworkto_blocktimeframefrom_blockto_timestampfrom_timestampresponse_formatinclude_address_activity

portal_substrate_query_events

Find Polkadot events

Query raw Substrate or Polkadot event rows with pallet/event-name filters and optional parent call or extrinsic context. COMMON USER ASKS: - Balances.Transfer events on Polkadot FIRST CHOICE FOR: - raw Substrate or Polkadot event rows with optional parent call or extrinsic context WHEN TO USE: - You need raw event records on a Substrate network. - You want pallet-level event activity like Balances.Transfer or Contracts.ContractEmitted. - You want event rows first, even if the network is a Polkadot-family chain. DON'T USE: - You want calls or aggregate analytics rather than event rows. EXAMPLES: - Balances.Transfer events on Polkadot: {"network":"polkadot","timeframe":"1h","event_names":["Balances.Transfer"],"limit":20}

Parameterslimitcursornetworkto_blocktimeframefrom_blockevent_namesinclude_callto_timestampinclude_stackfinalized_onlyfrom_timestamp+2 more

portal_substrate_query_calls

Find Polkadot calls

Query raw Substrate or Polkadot calls with pallet/call-name filters and optional child-call, emitted-event, or extrinsic context. COMMON USER ASKS: - Recent Balances calls - Polkadot calls with emitted events FIRST CHOICE FOR: - raw Substrate or Polkadot call rows, especially when you want the events emitted by those calls WHEN TO USE: - You need raw call records on a Substrate network. - You want pallet call activity like Balances.transfer_keep_alive or Ethereum.transact. - You want calls plus the events emitted by those calls. DON'T USE: - You want events or aggregate analytics rather than call rows. EXAMPLES: - Recent Balances calls: {"network":"polkadot","timeframe":"1h","call_names":["Balances.transfer_keep_alive"],"limit":20} - Polkadot calls with emitted events: {"network":"polkadot","timeframe":"1h","call_names":["ParaInherent.enter"],"include_events":true,"limit":20}

Parameterslimitcursornetworkto_blocktimeframecall_namesfrom_blockto_timestampinclude_stackfinalized_onlyfrom_timestampinclude_events+3 more

portal_substrate_get_analytics

Analyze Polkadot activity

Analytics snapshot for Substrate or Polkadot activity in an indexed window, with event, call, and extrinsic counts plus top event and call names. COMMON USER ASKS: - Polkadot activity snapshot - Big picture for Polkadot activity - How is Polkadot doing? FIRST CHOICE FOR: - Polkadot activity analytics in an indexed window - how Polkadot is doing in an indexed window - analytics snapshot for Polkadot or another Substrate network in an indexed window WHEN TO USE: - You want Polkadot activity analytics in a selected indexed window. - You want to ask "how is Polkadot doing in this indexed window?" and get an analytics answer rather than just network freshness metadata. - You want a quick Substrate network snapshot or health check. - You want top pallet events and calls rather than raw rows. - You want to know how a Substrate network is doing in the selected indexed window. DON'T USE: - You need full raw event or call records. EXAMPLES: - Polkadot activity snapshot: {"network":"polkadot","timeframe":"1h"} - Big picture for Polkadot activity: {"network":"polkadot","timeframe":"1h"} - How is Polkadot doing?: {"network":"polkadot","timeframe":"6h"}

Parametersmodenetworkto_blocktimeframefrom_blockto_timestampsection_limitfrom_timestampresponse_format

portal_hyperliquid_query_fills

Find Hyperliquid trades

Query raw individual Hyperliquid fills with trader, coin, fee, PnL, and builder context. COMMON USER ASKS: - Recent BTC fills WHEN TO USE: - You need raw fill records on Hyperliquid. - You want to filter by trader, coin, direction, builder, or fee token. DON'T USE: - You want the big picture, top traders, grouped aggregates, or candles instead of raw fill rows. EXAMPLES: - Recent BTC fills: {"network":"hyperliquid-fills","timeframe":"1h","coin":["BTC"],"limit":20}

Parametersdircoinusercloidlimitcursorbuildernetworkto_blockfee_tokentimeframefrom_block+6 more

portal_hyperliquid_get_analytics

Analyze Hyperliquid trading

Get the big-picture Hyperliquid fill analytics with top traders, volume by coin, fees, and PnL. COMMON USER ASKS: - Hyperliquid fill snapshot - Who traded the most? WHEN TO USE: - You want network-level Hyperliquid fill analytics. - You want to know who traded the most, which coins had volume, or how fees and PnL looked. - You want grouped aggregate sections without stitching raw fills together yourself. DON'T USE: - You need individual fill records or OHLC candles. EXAMPLES: - Hyperliquid fill snapshot: {"network":"hyperliquid-fills","timeframe":"1h"} - Who traded the most?: {"network":"hyperliquid-fills","timeframe":"1h"}

Parameterscoinmodecursornetworktimeframeto_timestampsection_limitfrom_timestampresponse_format

portal_hyperliquid_get_ohlc

Chart Hyperliquid prices

Build chart-ready Hyperliquid trade OHLC candles with fixed buckets and auto intervals. COMMON USER ASKS: - BTC candles WHEN TO USE: - You want candles for one coin on Hyperliquid. - You need chart-ready OHLC, volume, and VWAP data from fills. DON'T USE: - You want scalar time-series buckets or raw fills. EXAMPLES: - BTC candles: {"network":"hyperliquid-fills","coin":"BTC","duration":"6h","interval":"auto"}

Parameterscoinusercursornetworkdurationintervalto_timestampfrom_timestamp

portal_tron_query_transactions

Find Tron transactions

Query raw Tron transactions: native TRX transfers, TRC-10 asset transfers, TriggerSmartContract calls by contract and method, or any contract type, with optional inline logs and internal transactions. COMMON USER ASKS: - Recent native TRX transfers - USDT transfer calls in a block window - TRX sent from one wallet FIRST CHOICE FOR: - native TRX transfers, TRC-10 transfers, and smart-contract calls on Tron - who sent TRX to an address on Tron, or which wallets called a Tron contract WHEN TO USE: - You need raw Tron transaction records with sender, recipient, amount in TRX, fee, energy, and success. - You want native TRX transfers to or from a wallet in a bounded window. - You want calls to a Tron contract such as USDT filtered by method (transfer, approve) or caller. - You want TRC-10 asset transfers by asset id. DON'T USE: - You need TRC-20 token events; those are logs, so use portal_tron_query_logs. - You need an Ethereum-compatible network; use portal_evm_query_transactions. EXAMPLES: - Recent native TRX transfers: {"network":"tron-mainnet","timeframe":"5m","kind":"transfer","limit":20} - USDT transfer calls in a block window: {"network":"tron-mainnet","from_block":84000000,"to_block":84000010,"contract_addresses":["TR7NHqjeKQxGTCi8q8ZY4pL8otSzgjLj6t"],"method":"transfer","limit":20} - TRX sent from one wallet: {"network":"tron-mainnet","timeframe":"1h","kind":"transfer","from_addresses":["TR7NHqjeKQxGTCi8q8ZY4pL8otSzgjLj6t"],"limit":20}

Parameterskindassetlimittypescursormethodnetworksighashto_blocktimeframefrom_blockinclude_logs+9 more

portal_tron_query_logs

Find Tron contract events

Query raw Tron (TVM) event logs by contract address and topics with common event aliases, the parent transaction hash on every row, and optional inline decoding. COMMON USER ASKS: - Recent USDT transfers on Tron - USDT transfers received by one wallet FIRST CHOICE FOR: - TRC-20 token transfer events on Tron such as USDT - contract event evidence on Tron with the parent transaction hash WHEN TO USE: - You need TRC-20 Transfer or Approval events for a token such as USDT on Tron. - You need event logs from a Tron contract filtered by topic signature or indexed address. - You want the exact transaction hash behind each Tron event. DON'T USE: - You want native TRX transfers or contract calls; use portal_tron_query_transactions. - You need an Ethereum-compatible network; use portal_evm_query_logs. EXAMPLES: - Recent USDT transfers on Tron: {"network":"tron-mainnet","timeframe":"5m","addresses":["TR7NHqjeKQxGTCi8q8ZY4pL8otSzgjLj6t"],"event":"transfer","decode":true,"limit":20} - USDT transfers received by one wallet: {"network":"tron-mainnet","from_block":84000000,"to_block":84000100,"addresses":["TR7NHqjeKQxGTCi8q8ZY4pL8otSzgjLj6t"],"event":"transfer","topic2":["TJLuVi6UhS3UTx5EUXNCoz9VNqP2gnPmyf"],"decode":true,"limit":20}

Parameterseventlimitcursordecodetopic0topic1topic2topic3networkto_blockaddressestimeframe+7 more

portal_debug_query_blocks

Inspect raw blocks

ADVANCED: Query raw block records directly for EVM, Solana, or Bitcoin. COMMON USER ASKS: - Recent Base blocks WHEN TO USE: - You are debugging Portal coverage or block-level fields. - You need raw block records instead of transactions, logs, or summaries. DON'T USE: - You are answering a normal end-user question; prefer recent activity, time series, or raw transaction tools first. EXAMPLES: - Recent Base blocks: {"network":"base-mainnet","timeframe":"1h","limit":5}

Parameterslimitcursornetworkto_blocktimeframefrom_blockfield_presetto_timestampfinalized_onlyfrom_timestampinclude_l2_fields

portal_debug_resolve_time_to_block

Match a time to a block

ADVANCED: Resolve a timestamp to the nearest indexed block or slot. COMMON USER ASKS: - Resolve one hour ago on Base - Resolve an older time on Polkadot WHEN TO USE: - You are debugging timestamp windows or building a manual block-range query. - You want to inspect exact versus estimated timestamp-to-block resolution. DON'T USE: - You just want to query by time; most public tools already accept natural timestamps directly. EXAMPLES: - Resolve one hour ago on Base: {"network":"base-mainnet","timestamp":"1h ago"} - Resolve an older time on Polkadot: {"network":"polkadot","timestamp":"2026-04-08T12:00:00Z"}

Parametersnetworkrequiredtimestamprequired

portal_debug_hyperliquid_query_replica_commands

Inspect Hyperliquid command records

ADVANCED: Query Hyperliquid replica-command actions such as orders, cancels, and leverage updates. COMMON USER ASKS: - Recent order action WHEN TO USE: - You are debugging Hyperliquid replica-command records. - You need raw order-action events instead of fills or analytics. DON'T USE: - You only need public trading activity; fills and analytics are usually the better fit. EXAMPLES: - Recent order action: {"network":"hyperliquid-replica-cmds","timeframe":"5m","limit":1}

Parametersuserlimitcursorstatusnetworkto_blocktimeframefrom_blockaction_typeto_timestampvault_addressfinalized_only+1 more

Version history

1
  1. v0.8.5LatestSep 16, 2026

Score

100% of the applicable checks met

How complete this listing is, computed from the registry entry, the endpoint and public sources. Not a rating of the server and not a statement that it is safe or working today: reachability is a dated check, and no installs or reviews go into the score.

  • Reached in the last 30 daysRequired25 pts
  • Auth declaredRequired10 pts
  • Tools listedRequired15 pts
  • DescriptionRequired15 pts
  • Logo10 pts
  • Documentation15 pts
  • License10 pts