When we started building Agent RPC, the plan was to ship an MCP server that let an agent do both halves of the job: read the blockchain, and run the Ankr account paying for those reads. We created a working version quickly, and then it became clear the interesting problem wasn't the server, but what the server was handing the model.

So we built a wire format instead. TORPC, short for Token Optimized RPC, is an open spec that changes how RPC responses are encoded without changing what they mean. It's the foundation Agent RPC sits on, and it's the reason the same chain read lands in the model's context at roughly half the tokens.

Here is the purpose of it in one example: A Uniswap V3 swap receipt from Ethereum mainnet costs 1,357 tokens to put in front of a model in standard JSON-RPC. Through TORPC, that same receipt is 529. It’s the same transaction and same facts available to the model, 61% fewer tokens.

Use Agent RPC Now

Why we built a format and not a helper library

RPC responses were designed for parsers, and they're very good at that job. They're bad at the job an agent actually needs, which is handing a language model something it can reason about.

Every receipt carries a logsBloom field, 512 hex characters of probabilistic index that exists so light clients can skip blocks. It's redundant with the log array printed directly underneath it, and you pay for it on every read. Block hashes and transaction hashes get repeated inside every log entry. Numbers arrive as hex strings the model has to convert before it can do arithmetic. Token amounts arrive as raw integers with no decimals attached, so a model looking at a transfer can't tell from the payload whether it's dealing with six decimals or eighteen. On top of all that, hex is close to the worst possible input for a tokenizer. Ordinary text compresses because tokenizers learn the patterns in language, and a keccak hash has no patterns, so it fragments into far more tokens than its length suggests.

Cleaning that up after the fact is easy enough to do poorly. Write a helper, strip some fields, ship it. We went to a format for three reasons that a library can't cover.

The first is determinism. Prompt caching depends on byte-stable prefixes, and a transform that reorders keys or drifts between calls breaks every cache hit downstream and costs you more than it saves. TORPC specifies identical output for identical input as a contract, not an implementation detail.

The second is negotiation. Different agents want different things from the same response, and that decision belongs in the request, not in a client-side cleanup step after you've already paid to transmit the bytes.

The third is that this shouldn't be ours. An encoding one provider controls is a lock-in with better marketing. If chain data is going to be readable by models, the fix has to be something any RPC provider can implement and any client can verify.

How TORPC works

TORPC is opt-in with a header. Send nothing, and you get standard JSON-RPC exactly as you always have, byte for byte, which means existing integrations are untouched. Ask for it, and you pick a tier.

Tier 1 is mechanical. It drops service fields (logsBloom, cumulativeGasUsed, transactionIndex, type), hoists the hashes every log repeats, shortens field names (blockNumber becomes block, transactionHash becomes tx), and re-encodes hex integers as decimal strings. It is a shape change, not just a diet, so a client that opts in reads the new names. Transforms on the fields it keeps are mechanically reversible; the dropped service fields are gone by policy, and some of them cannot be recomputed from what remains, so you get the raw form back by re-issuing the request without the header against the same block.

Tier 2 decodes. Event signatures resolve to names, log topics and data become a named args object, and transaction calldata becomes a function name with its arguments. Amounts stay in raw base units, so a caller that wants a human figure still reads the token's decimals. Where the ABI cannot be resolved the raw element is kept in place and flagged, and the server never invents a decoding. The model receives the fact instead of an encoding of the fact, which is the difference between a model that answers your question and a model that spends its first pass working out what it's looking at.

Roughly half the tokens, measured in production

Live capture on mcp.ankr.com, that same Uniswap receipt, raw against tier 2: 1,357 tokens down to 529, a 61% reduction.

In a live run against production on 2026-07-17, across the 21 methods that answer with a transformed tier, 25 random Ethereum mainnet blocks each: 35.3% at tier 1 and 48.4% at tier 2, token-weighted over the full HTTP response body. Coverage is 23 methods, ten of them reaching tier 2 and thirteen tier 1.

See full results on GitHub

Across the full benchmark corpus: 1.87 million tokens down to 1.03 million, 45%.

What that means in practice depends on your loop. Point an agent at a wallet's last 500 transactions and you're around 680,000 tokens of raw receipt data for one task, which doesn't fit in a 200k window. The agent chunks it, summarizes, loses detail, comes back for another look, and every pass bills again. Cutting the payload in half doesn't just halve the line item. It changes how many of those passes you need.

We deleted half the bytes and the models got more accurate

We ran the same models against the same questions on raw RPC and on tier 2 output, expecting equal scores at half the price. The compressed runs scored higher.

Method: 100 questions x 3 tiers = 300 evaluations per model over 114 pinned Ethereum mainnet items, answered through the Anthropic API as a plain chat completion with no tools, so the model reads the payload instead of running code over it. Scoring is deterministic and type-aware; no LLM judge. The table is the like-for-like bucket of 85 questions whose raw payload fits the model's context window; the remaining 15 overflow even at tier 2 on a 200K window and are counted as a capacity failure, not a wrong answer.

The convergence is the part worth sitting with. Models that were ten points apart on raw data finish within two points of each other, which suggests the raw encoding was taxing the weaker model hardest. Clear the encoding away and most of the gap closes.

Scope, honestly: these are Claude family runs only. GPT and Gemini are still pending, and we're not calling this a multi-model result until they're done.

Why it's open, and why you should check our work

The spec is public and CC0 at w3tech/torpc. The benchmark is public here. Both the strong cases and the weak ones are in there, because a compression number without a counterexample is a marketing claim, and we'd rather you rerun the thing than take our word for it.

We're taking it to the standards track for the same reason. TORPC is more valuable to us as something the ecosystem implements than as an Ankr feature, and it's only credible as a format if someone other than us can build it.

Why TORPC is the core of Agent RPC

Everything else Agent RPC does rides on TORPC. The 17 named data tools, the indexed cross-chain reads over 29 networks, the escape hatch to any read method on any chain we serve, the management plane where your agent runs keys and allowlists and billing through the same connection. All of it is answering in TORPC, and all of it is roughly half the tokens it would otherwise be.

The same principle shapes the tool surface. Tool definitions get re-sent on every request, so a big tool list is a standing charge before your agent has done anything. A default Agent RPC session measures 8,557 tokens of tool surface against roughly 34,000 for large competing MCP servers. Ours reaches that number too if you load every group, the difference being that you never have to. Account tools come in eight loadable groups, and an agent that needs billing halfway through a session pulls that group without reconnecting or signing in again.

Without TORPC, Agent RPC would be one more MCP server. With it, the cost of running an agent that reads chains is a different number.

Try it now

Both planes are live. You'll need an API key from Ankr.

Data plane at mcp.ankr.com/rpc, authenticated with your key in the x-ankr-api-key header. Tier 2 is verified on 22 EVM networks today, and the raw-RPC tools reach any chain Ankr serves. The Advanced API indexed reads cover 29 networks.

Management plane at mcp.ankr.com/mcp, browser sign-in once through OAuth, after which your agent can run the account paying for those reads.

Quickstart link

Connecting takes about two minutes in Claude Code or Cursor and nothing in your existing setup has to change. If you send no header, nothing does.