<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>Ethers-Js on BLAZED.sh Blog</title>
    <link>https://blazed.sh/blog/tags/ethers-js/</link>
    <description>Recent content in Ethers-Js on BLAZED.sh Blog</description>
    <generator>Hugo</generator>
    <language>en-us</language>
    <lastBuildDate>Thu, 23 Jul 2026 07:19:00 +0000</lastBuildDate>
    <atom:link href="https://blazed.sh/blog/tags/ethers-js/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>ERC-20 Transfer Webhooks: Build One in 50 Lines on a Co-located Node</title>
      <link>https://blazed.sh/blog/posts/erc20-transfer-webhooks/</link>
      <pubDate>Thu, 23 Jul 2026 07:19:00 +0000</pubDate>
      <guid>https://blazed.sh/blog/posts/erc20-transfer-webhooks/</guid>
      <description>&lt;p&gt;The most requested webhook on Ethereum is also the simplest to describe: tell my backend when this token moves, or when this wallet receives funds. Exchange deposit flows, payment confirmations, treasury alerts and airdrop trackers are all variations of that one sentence. Search for an ERC-20 transfer webhook and you will mostly find hosted products that charge per delivered event, but underneath every one of them sits a primitive small enough to read in one sitting: an &lt;code&gt;eth_subscribe&lt;/code&gt; log filter on one side and an HTTP POST on the other.&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>How to Access the Ethereum Mempool: Streaming Pending Transactions From a Co-located Node</title>
      <link>https://blazed.sh/blog/posts/how-to-access-ethereum-mempool/</link>
      <pubDate>Sat, 20 Jun 2026 14:00:00 +0000</pubDate>
      <guid>https://blazed.sh/blog/posts/how-to-access-ethereum-mempool/</guid>
      <description>&lt;p&gt;Every transaction spends a moment in limbo between &amp;ldquo;broadcast&amp;rdquo; and &amp;ldquo;mined&amp;rdquo;. That waiting room is the mempool, and it is where a lot of the interesting work in Ethereum happens: a searcher spots an arbitrage before it lands, a bot front-runs a large swap, a liquidation watcher sees the transaction that will tip a position underwater. If you want to act on a transaction before it is final, you have to read the mempool.&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>
