<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>Json-Rpc on BLAZED.sh Blog</title>
    <link>https://blazed.sh/blog/tags/json-rpc/</link>
    <description>Recent content in Json-Rpc on BLAZED.sh Blog</description>
    <generator>Hugo</generator>
    <language>en-us</language>
    <lastBuildDate>Sat, 01 Aug 2026 14:00:00 +0000</lastBuildDate>
    <atom:link href="https://blazed.sh/blog/tags/json-rpc/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>Ethereum RPC Latency in 2026: IPC vs WebSocket vs Remote Providers, Measured</title>
      <link>https://blazed.sh/blog/posts/ethereum-rpc-latency-benchmark/</link>
      <pubDate>Sat, 01 Aug 2026 14:00:00 +0000</pubDate>
      <guid>https://blazed.sh/blog/posts/ethereum-rpc-latency-benchmark/</guid>
      <description>&lt;p&gt;Every RPC provider sells latency and almost nobody publishes a distribution. You get a marketing average, occasionally a p95 on a status page, and never the methodology. We wrote a &lt;a href=&#34;https://blazed.sh/blog/posts/ipc-vs-http-websocket-ethereum-rpc&#34;&gt;transport comparison&lt;/a&gt; last June that leaned on illustrative ranges because we had not measured them ourselves, and that has bothered us since. So this post measures instead: nine public Ethereum endpoints, up to 300 samples each, percentiles rather than means, a race between three subscription feeds to see who learns about a new block first, and a separate benchmark of what a JSON-RPC round-trip costs when there is no network in the path at all.&lt;/p&gt;</description>
    </item>
    <item>
      <title>eth_getLogs Block Range Limits: Why Your Queries Fail and How to Fetch 1,000 Blocks at Once</title>
      <link>https://blazed.sh/blog/posts/eth-getlogs-block-range-limit/</link>
      <pubDate>Sat, 20 Jun 2026 14:30:11 +0000</pubDate>
      <guid>https://blazed.sh/blog/posts/eth-getlogs-block-range-limit/</guid>
      <description>&lt;p&gt;If you have ever indexed an ERC-20, backfilled a DEX, or built a liquidation monitor, you have met this error:&lt;/p&gt;&#xA;&lt;div class=&#34;highlight&#34;&gt;&lt;pre tabindex=&#34;0&#34; class=&#34;chroma&#34;&gt;&lt;code class=&#34;language-text&#34; data-lang=&#34;text&#34;&gt;&lt;span class=&#34;line&#34;&gt;&lt;span class=&#34;cl&#34;&gt;query returned more than 10000 results&#xA;&lt;/span&gt;&lt;/span&gt;&lt;/code&gt;&lt;/pre&gt;&lt;/div&gt;&lt;p&gt;Or one of its many cousins: &lt;code&gt;Exceed maximum block range: 5000&lt;/code&gt;, &lt;code&gt;eth_getLogs is limited to a 1024 block range&lt;/code&gt;, or a silent &lt;code&gt;query timeout&lt;/code&gt;. They all mean the same thing: your &lt;code&gt;eth_getLogs&lt;/code&gt; call asked for more than the provider is willing to return in one request. This post explains why those limits exist, lists where the common providers draw the line, and shows a chunking strategy that fetches any range reliably. At the end we look at why running your code on the node sidesteps most of the pain entirely.&lt;/p&gt;</description>
    </item>
    <item>
      <title>IPC vs HTTP vs WebSocket: The Fastest Way to Talk to an Ethereum Node</title>
      <link>https://blazed.sh/blog/posts/ipc-vs-http-websocket-ethereum-rpc/</link>
      <pubDate>Wed, 17 Jun 2026 14:00:00 +0000</pubDate>
      <guid>https://blazed.sh/blog/posts/ipc-vs-http-websocket-ethereum-rpc/</guid>
      <description>&lt;p&gt;Every Ethereum RPC call travels over a transport, and the transport you pick sets a floor on how fast that call can ever be. For a wallet showing a balance, the difference is invisible. For an arbitrage bot that reads a price and decides whether to act before the next block, it is the whole game. This post compares the three transports your node speaks, HTTP, WebSocket, and IPC, explains where their latency comes from, and gives you a benchmark you can run to see the gap on your own setup.&lt;/p&gt;</description>
    </item>
  </channel>
</rss>
