<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>Blazed.sh on BLAZED.sh Blog</title>
    <link>https://blazed.sh/blog/tags/blazed.sh/</link>
    <description>Recent content in Blazed.sh on BLAZED.sh Blog</description>
    <generator>Hugo</generator>
    <language>en-us</language>
    <lastBuildDate>Wed, 16 Sep 2026 08:00:00 +0000</lastBuildDate>
    <atom:link href="https://blazed.sh/blog/tags/blazed.sh/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>FOCIL and MEV: Inclusion Is Not Transaction Ordering</title>
      <link>https://blazed.sh/blog/posts/focil-inclusion-vs-ordering/</link>
      <pubDate>Tue, 15 Sep 2026 08:00:00 +0000</pubDate>
      <guid>https://blazed.sh/blog/posts/focil-inclusion-vs-ordering/</guid>
      <description>&lt;p&gt;A transaction can be included in a block and still be useless to your bot. A competing liquidation can execute first. A swap can move the pool price before your arbitrage runs. Your own transaction can appear in the block with a failed receipt and a gas bill.&lt;/p&gt;&#xA;&lt;p&gt;That distinction matters when reading about FOCIL, short for fork-choice enforced inclusion lists. &lt;a href=&#34;https://eips.ethereum.org/EIPS/eip-7805&#34;&gt;EIP-7805&lt;/a&gt; proposes a way for validators to constrain which transactions builders may omit. It does not give a searcher a reservation at the top of a block, and it does not make an included transaction succeed.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Flashbots Bundle Not Included: Why a Profitable Bundle Doesn&#39;t Land</title>
      <link>https://blazed.sh/blog/posts/flashbots-bundle-not-included/</link>
      <pubDate>Sun, 13 Sep 2026 08:00:00 +0000</pubDate>
      <guid>https://blazed.sh/blog/posts/flashbots-bundle-not-included/</guid>
      <description>&lt;p&gt;A bundle hash is an acknowledgement, not a receipt. A successful simulation is a result for a chosen state and execution environment, not a reservation in the next block. Keeping those two distinctions in your logs makes a missing bundle much easier to investigate.&lt;/p&gt;&#xA;&lt;p&gt;The &lt;a href=&#34;https://docs.flashbots.net/flashbots-auction/advanced/troubleshooting&#34;&gt;Flashbots troubleshooting guide&lt;/a&gt; identifies several common causes: a transaction reverts, the incentive is insufficient, a competing bundle changes the opportunity, delivery is late, or the block producer does not use the relevant builder path. More than one can apply to the same attempt.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Uniswap V4 Hooks: Dynamic Fees and Swap Simulation for Bots</title>
      <link>https://blazed.sh/blog/posts/uniswap-v4-hooks-bot-simulation/</link>
      <pubDate>Fri, 11 Sep 2026 08:00:00 +0000</pubDate>
      <guid>https://blazed.sh/blog/posts/uniswap-v4-hooks-bot-simulation/</guid>
      <description>&lt;p&gt;Two Uniswap v4 pools can trade the same currencies and behave differently. One charges a fixed LP fee. Another uses a hook to change the fee for each swap. A third checks the caller, modifies accounting or rejects the operation under conditions your reserve calculation does not model.&lt;/p&gt;&#xA;&lt;p&gt;For a bot, a pool&amp;rsquo;s price is therefore not enough to describe the trade. You need the pool key, hook address, execution path and state used for simulation. A successful quote through one caller does not prove the same swap succeeds through your executor.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Hegotá Explained: What the EF&#39;s EIP Tier List Tells Us About Ethereum&#39;s Next-Next Fork</title>
      <link>https://blazed.sh/blog/posts/hegota-eip-tier-list/</link>
      <pubDate>Tue, 08 Sep 2026 10:00:00 +0000</pubDate>
      <guid>https://blazed.sh/blog/posts/hegota-eip-tier-list/</guid>
      <description>&lt;p&gt;Glamsterdam has not shipped yet; it is live on the Platåberget testnet and heads to Sepolia and Hoodi next, as covered in &lt;a href=&#34;https://blazed.sh/blog/posts/glamsterdam-ethereum-upgrade&#34;&gt;our Glamsterdam hub&lt;/a&gt;. But Ethereum&amp;rsquo;s fork pipeline does not wait. On September 7, 2026, the Ethereum Foundation&amp;rsquo;s Protocol Cluster published &lt;a href=&#34;https://blog.ethereum.org/2026/09/07/protocol-hegota-eips&#34;&gt;&amp;ldquo;The Hegotá EIP Opinion Post and Tier List&amp;rdquo;&lt;/a&gt;, the first real look at the scope of Hegotá, the fork after Glamsterdam. It grades 62 candidate EIPs using 397 individual assessments from across the Protocol Cluster, and it names exactly two of them must-ship.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Detect New Uniswap Pools on Ethereum: V2, V3 and V4 With ethers.js</title>
      <link>https://blazed.sh/blog/posts/detect-new-uniswap-pools-ethers/</link>
      <pubDate>Mon, 07 Sep 2026 08:00:00 +0000</pubDate>
      <guid>https://blazed.sh/blog/posts/detect-new-uniswap-pools-ethers/</guid>
      <description>&lt;p&gt;A Uniswap v2 pool has its own contract address. So does a v3 pool. A v4 pool does not: it lives inside the singleton PoolManager and is identified by a &lt;code&gt;PoolId&lt;/code&gt;.&lt;/p&gt;&#xA;&lt;p&gt;That difference breaks a common new-pool detector. Watching newly deployed contracts can find v2 and v3 pools, but it is the wrong signal for v4. Watch the protocol&amp;rsquo;s creation or initialization events instead, and preserve the fields that identify the pool.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Why Are Pending Transactions Missing From the Mempool Feed?</title>
      <link>https://blazed.sh/blog/posts/missing-pending-transactions/</link>
      <pubDate>Sat, 05 Sep 2026 08:00:00 +0000</pubDate>
      <guid>https://blazed.sh/blog/posts/missing-pending-transactions/</guid>
      <description>&lt;p&gt;Your subscription emits a transaction hash. You immediately request the transaction and get &lt;code&gt;null&lt;/code&gt;. Or a transaction lands in a block, but its hash never appeared in your pending feed.&lt;/p&gt;&#xA;&lt;p&gt;Those symptoms are different. The first proves that your subscription delivered a particular hash but a later lookup could not resolve it. The second only proves that you did not record a pending notification. Neither, by itself, identifies replacement, eviction or private submission.&lt;/p&gt;</description>
    </item>
    <item>
      <title>How to Benchmark Ethereum RPC for Trading Bots</title>
      <link>https://blazed.sh/blog/posts/benchmark-ethereum-rpc-trading-bots/</link>
      <pubDate>Thu, 03 Sep 2026 08:00:00 +0000</pubDate>
      <guid>https://blazed.sh/blog/posts/benchmark-ethereum-rpc-trading-bots/</guid>
      <description>&lt;p&gt;A fast response to &lt;code&gt;eth_blockNumber&lt;/code&gt; tells you how quickly an endpoint can return a small piece of data. It does not tell you when that endpoint learned about the block, whether twenty pool reads will finish before your deadline, or whether the transaction you submit will reach a builder in time.&lt;/p&gt;&#xA;&lt;p&gt;Our &lt;a href=&#34;https://blazed.sh/blog/posts/free-tier-rpc-latency-vs-colocated-node-benchmark&#34;&gt;free-tier RPC comparison&lt;/a&gt; measured request latency, burst capacity and head delivery separately. This post is the method you can apply to your own bot. It is not a new provider ranking, and it does not reuse those measurements as if they were taken today.&lt;/p&gt;</description>
    </item>
    <item>
      <title>An MCP Server in One Bash File</title>
      <link>https://blazed.sh/blog/posts/mcp-server-in-one-bash-file/</link>
      <pubDate>Mon, 10 Aug 2026 16:00:00 +0000</pubDate>
      <guid>https://blazed.sh/blog/posts/mcp-server-in-one-bash-file/</guid>
      <description>&lt;p&gt;BLAZED.sh is a PaaS for latency-sensitive workloads. Users can deploy OCI containers or run JavaScript scripts without managing the servers below them.&lt;/p&gt;&#xA;&lt;p&gt;The platform already had a REST API, and while building our CLI we also wanted an MCP server. An agent should be able to deploy something, stop it and read its logs using the same API as everyone else. Our first thought was to start another TypeScript project and install an MCP SDK. Then we realized that the Bash CLI already did nearly all of the work.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Alchemy vs Infura vs QuickNode: Free Tier RPC Latency Against a Co-located Node</title>
      <link>https://blazed.sh/blog/posts/free-tier-rpc-latency-vs-colocated-node-benchmark/</link>
      <pubDate>Mon, 10 Aug 2026 10:00:00 +0000</pubDate>
      <guid>https://blazed.sh/blog/posts/free-tier-rpc-latency-vs-colocated-node-benchmark/</guid>
      <description>&lt;p&gt;Our &lt;a href=&#34;https://blazed.sh/blog/posts/ethereum-rpc-latency-benchmark&#34;&gt;August RPC latency benchmark&lt;/a&gt; measured nine keyless public endpoints and left two gaps that the post named itself: no account-backed endpoint was tested, and our own node was not in the table. This study closes both.&lt;/p&gt;&#xA;&lt;p&gt;We registered accounts with Alchemy, Infura and QuickNode, measured their endpoints against six keyless ones, added our own production node from two separate vantage points, and added a dimension the first run missed entirely: what happens when you stop sending one request at a time and start sending the burst a strategy actually sends when a block lands.&lt;/p&gt;</description>
    </item>
    <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>BLAZED.sh Now Has a Free Tier: 1M RPC Credits and a Live Script on the Node</title>
      <link>https://blazed.sh/blog/posts/free-tier-launch/</link>
      <pubDate>Fri, 31 Jul 2026 09:00:00 +0000</pubDate>
      <guid>https://blazed.sh/blog/posts/free-tier-launch/</guid>
      <description>&lt;p&gt;Until now the only way to find out what running your code on the node actually feels like was to pay for the Beta plan or poke at the &lt;a href=&#34;https://demo.blazed.sh&#34;&gt;live demo panel&lt;/a&gt;. That was the wrong shape for a product whose whole pitch is a latency difference you have to measure yourself. So there is now a free plan: one always-on JavaScript script, running on a host with a fully synced Ethereum mainnet node, with 1,000,000 RPC credits a month. No card, no trial clock.&lt;/p&gt;</description>
    </item>
    <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>EIP-3156: The Flash Loan Standard, Explained</title>
      <link>https://blazed.sh/blog/posts/eip-3156-flash-loans-standard/</link>
      <pubDate>Wed, 22 Jul 2026 12:41:00 +0000</pubDate>
      <guid>https://blazed.sh/blog/posts/eip-3156-flash-loans-standard/</guid>
      <description>&lt;p&gt;Flash loans are the purest expression of what makes Ethereum programmable money: you can borrow millions of dollars with no collateral and no credit check, provided you give it all back before the transaction ends. &lt;a href=&#34;https://eips.ethereum.org/EIPS/eip-3156&#34;&gt;EIP-3156&lt;/a&gt; is the attempt to give that primitive one standard interface, so that a borrower contract written once can take liquidity from any compliant lender. This post covers the primitive itself, the two interfaces with real Solidity, a minimal borrower, the security model behind the odd-looking magic return value, and the honest adoption picture.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Arbitrage Basics: How to Build a Crypto Arbitrage Bot</title>
      <link>https://blazed.sh/blog/posts/how-to-build-crypto-arbitrage-bot/</link>
      <pubDate>Tue, 21 Jul 2026 14:26:00 +0000</pubDate>
      <guid>https://blazed.sh/blog/posts/how-to-build-crypto-arbitrage-bot/</guid>
      <description>&lt;h2 id=&#34;welcome-back-to-arbitrage-basics&#34;&gt;Welcome Back to Arbitrage Basics&lt;/h2&gt;&#xA;&lt;p&gt;This is part three of our arbitrage series, and it is the one where the math starts running. &lt;a href=&#34;https://blazed.sh/blog/posts/tri_arbitrage&#34;&gt;Part one&lt;/a&gt; built a triangular arbitrage checker for Uniswap V2 and walked through pairs, reserves, and the exact &lt;code&gt;getAmountOut&lt;/code&gt; formula. &lt;a href=&#34;https://blazed.sh/blog/posts/graph_theory_arbitrage&#34;&gt;Part two&lt;/a&gt; generalized detection with graph theory: tokens become vertices, pairs become edges weighted by negative log exchange rates, and Bellman-Ford surfaces profitable cycles of any length as negative cycles. Both posts end at the same place, a function that takes fresh reserves and returns candidate trading loops.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Glamsterdam Explained: Every EIP in Ethereum&#39;s Next Upgrade</title>
      <link>https://blazed.sh/blog/posts/glamsterdam-ethereum-upgrade/</link>
      <pubDate>Tue, 21 Jul 2026 07:58:00 +0000</pubDate>
      <guid>https://blazed.sh/blog/posts/glamsterdam-ethereum-upgrade/</guid>
      <description>&lt;p&gt;Glamsterdam is the next Ethereum hard fork after Fusaka, and it is shaping up as the most structural release the network has shipped in years. It moves the block-building auction into the protocol itself, puts a consensus-verified state diff inside every block, and reprices the corners of the EVM that stood in the way of much higher gas limits. Multi-client devnets have been running the full slate since June 2026, the public Platåberget testnet forked on August 20, and ethereum.org now puts mainnet activation in Q4 2026.&lt;/p&gt;</description>
    </item>
    <item>
      <title>What Is a MEV Searcher? Infrastructure, Latency, and Whether You Need Your Own Node</title>
      <link>https://blazed.sh/blog/posts/what-is-a-mev-searcher/</link>
      <pubDate>Mon, 20 Jul 2026 13:47:00 +0000</pubDate>
      <guid>https://blazed.sh/blog/posts/what-is-a-mev-searcher/</guid>
      <description>&lt;p&gt;If you have read anything about MEV, you have met the word &amp;ldquo;searcher&amp;rdquo;. It is the working job title of everyone actually running the bots: the arbitrageur closing a price gap between two DEX pools, the liquidator watching health factors on a lending market, the operator whose bundle landed one block ahead of yours. The term gets used constantly and defined rarely. This post fixes that. It covers what a MEV searcher actually is, where they sit in Ethereum&amp;rsquo;s block-building pipeline, which strategies they run, what their infrastructure looks like in practice, and then the question almost everyone asks next: do you need to run your own node to compete?&lt;/p&gt;</description>
    </item>
    <item>
      <title>What Is ePBS? Ethereum&#39;s Enshrined Proposer-Builder Separation (EIP-7732), Explained</title>
      <link>https://blazed.sh/blog/posts/epbs-eip-7732-searchers-builders/</link>
      <pubDate>Mon, 20 Jul 2026 08:12:00 +0000</pubDate>
      <guid>https://blazed.sh/blog/posts/epbs-eip-7732-searchers-builders/</guid>
      <description>&lt;p&gt;ePBS stands for enshrined proposer-builder separation. &lt;a href=&#34;https://eips.ethereum.org/EIPS/eip-7732&#34;&gt;EIP-7732&lt;/a&gt; moves the builder&amp;rsquo;s payload commitment and its payment relationship with the proposer into Ethereum&amp;rsquo;s consensus rules. The proposer can commit to a builder&amp;rsquo;s block without relying on a relay to enforce that exchange.&lt;/p&gt;&#xA;&lt;p&gt;For searchers, the important change is timing. A consensus block and its execution payload no longer arrive as one object. The payload can arrive later, leaving less time to observe the new state, simulate a trade and reach the builder of the next block.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Infura Alternatives for High-Volume Ethereum RPC in 2026</title>
      <link>https://blazed.sh/blog/posts/infura-alternative/</link>
      <pubDate>Fri, 10 Jul 2026 10:00:00 +0000</pubDate>
      <guid>https://blazed.sh/blog/posts/infura-alternative/</guid>
      <description>&lt;p&gt;Infura is where most teams start, and for good reason: it is reliable, well documented, and free to begin with. The trouble usually shows up later, at scale, when the same properties that made it easy start to constrain you. If you are reading this, you have probably already hit a &lt;code&gt;429 Too Many Requests&lt;/code&gt;, watched a compute-unit bill climb, or realized your whole app depends on a single provider. This post is an honest look at the alternatives in 2026, what to weigh when choosing one, and where each option actually fits. Provider plans, quotas, and pricing change frequently; treat this as a qualitative snapshot as of July 2026 and check official docs before buying or migrating.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Alchemy Alternatives for Ethereum RPC in 2026</title>
      <link>https://blazed.sh/blog/posts/alchemy-alternative/</link>
      <pubDate>Fri, 10 Jul 2026 09:00:00 +0000</pubDate>
      <guid>https://blazed.sh/blog/posts/alchemy-alternative/</guid>
      <description>&lt;p&gt;Alchemy is often the first serious upgrade a team makes after outgrowing a free endpoint, and it earns that position: the SDK is pleasant, the enhanced APIs remove real work, and the free tier is generous enough to carry a project a long way. The reasons people start shopping for an alternative are rarely about quality. Usually it is the compute-unit meter climbing faster than traffic, the slow realization that the enhanced APIs which saved time have also become hard to leave, or a latency-sensitive workload that would rather sit next to the node than call across the internet to reach it. This post is an honest look at the alternatives in 2026, what to weigh, and where each one actually fits. Provider plans, compute-unit weights, and enhanced-API pricing change often; treat this as a qualitative snapshot as of July 2026 and confirm against official docs before you migrate.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Cheapest Ethereum RPC in 2026: How to Actually Pay Less</title>
      <link>https://blazed.sh/blog/posts/cheapest-ethereum-rpc/</link>
      <pubDate>Thu, 09 Jul 2026 08:00:00 +0000</pubDate>
      <guid>https://blazed.sh/blog/posts/cheapest-ethereum-rpc/</guid>
      <description>&lt;p&gt;Search for the cheapest Ethereum RPC and you get a list of headline prices, which is the one number that reliably fails to predict your invoice. The honest answer is that the cheapest provider depends on the shape of your traffic, and that the sticker price is only the floor. What actually decides the bill is how a model prices the heavy parts of your workload: traces, wide log queries, large responses, and bursts. This post breaks down where the real cost hides, which model is cheapest for which workload, and how to compare them without guessing. Plans and weights move often; treat the specifics here as a qualitative snapshot as of July 2026 and confirm against official docs before you commit.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Lean Ethereum: Vitalik&#39;s Third Rebuild of the Protocol, Explained</title>
      <link>https://blazed.sh/blog/posts/lean-ethereum-roadmap-explained/</link>
      <pubDate>Mon, 06 Jul 2026 10:00:00 +0000</pubDate>
      <guid>https://blazed.sh/blog/posts/lean-ethereum-roadmap-explained/</guid>
      <description>&lt;p&gt;Two weeks ago, Ethereum researchers met in Berlin to keep charting the protocol&amp;rsquo;s long-term trajectory, picking up threads from the client-team discussions held in Svalbard back in April. The output is an updated &lt;a href=&#34;https://strawmap.org/&#34;&gt;strawmap&lt;/a&gt;, the community&amp;rsquo;s deliberately provisional sketch of where the protocol is headed, and a set of high-level takeaways that Vitalik Buterin published on July 4. The framing that ties them together is a name: Lean Ethereum.&lt;/p&gt;&#xA;&lt;p&gt;It helps to be precise about what that name means, because it is easy to file under &amp;ldquo;another roadmap.&amp;rdquo; Lean Ethereum is not a single one-shot upgrade. It is a collection of improvements that will come online over the course of three or four years. But make no mistake: this is the third major iteration of Ethereum, in the same way that &lt;a href=&#34;https://ethereum.org/roadmap/merge/&#34;&gt;the Merge&lt;/a&gt; was the second. Almost every major piece of the protocol is on the table to be replaced, and the through-line is simplification, cleanup, and future-proofing, done in a way that minimizes disruption to the applications already running. Ethereum has done exactly this before with the transition from proof-of-work, so the precedent for a deep rebuild that users barely feel already exists.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Block-Level Access Lists Explained (EIP-7928)</title>
      <link>https://blazed.sh/blog/posts/block-level-access-lists-eip-7928/</link>
      <pubDate>Fri, 03 Jul 2026 10:00:00 +0000</pubDate>
      <guid>https://blazed.sh/blog/posts/block-level-access-lists-eip-7928/</guid>
      <description>&lt;p&gt;Glamsterdam, the next Ethereum upgrade after Fusaka, has two headline changes. The consensus-layer half is &lt;a href=&#34;https://blazed.sh/blog/posts/epbs-eip-7732-searchers-builders&#34;&gt;ePBS, EIP-7732&lt;/a&gt;, which restructures how blocks get built and has absorbed most of the attention. The execution-layer half is &lt;a href=&#34;https://eips.ethereum.org/EIPS/eip-7928&#34;&gt;EIP-7928, Block-Level Access Lists&lt;/a&gt;, and it is arguably the more practical change for anyone whose job is consuming Ethereum data rather than producing blocks. It is also further along than most people realize: &lt;a href=&#34;https://github.com/ethereum/go-ethereum/releases/tag/v1.17.4&#34;&gt;Geth 1.17.4&lt;/a&gt; already constructs and verifies BALs during block execution and serves them over the new &lt;code&gt;eth/71&lt;/code&gt; wire protocol, ahead of the fork activating anywhere public.&lt;/p&gt;</description>
    </item>
    <item>
      <title>QuickNode Alternatives for Ethereum RPC in 2026</title>
      <link>https://blazed.sh/blog/posts/quicknode-alternative/</link>
      <pubDate>Wed, 01 Jul 2026 09:00:00 +0000</pubDate>
      <guid>https://blazed.sh/blog/posts/quicknode-alternative/</guid>
      <description>&lt;p&gt;QuickNode is a strong product, and most teams that pick it are happy for a while. It is fast, it covers a long list of chains, and its add-on marketplace lets you switch on traces, token APIs, or a mempool feed without standing up your own infrastructure. The reasons people start shopping for an alternative are rarely about quality; they are about where the model stops fitting. Usually it is the credit meter climbing faster than traffic, an edge function bumping into its runtime ceiling, or the realization that the workload really wants to live next to the node rather than call across the internet to reach it. This post is an honest look at the alternatives in 2026, what to weigh, and where each one actually fits. Provider plans, credit weights, and add-on pricing change often; treat this as a qualitative snapshot as of July 2026 and confirm against official docs before you migrate.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Ethereum RPC Pricing Explained: Compute Units vs Credits</title>
      <link>https://blazed.sh/blog/posts/ethereum-rpc-pricing-compute-units-vs-credits/</link>
      <pubDate>Wed, 24 Jun 2026 09:00:00 +0000</pubDate>
      <guid>https://blazed.sh/blog/posts/ethereum-rpc-pricing-compute-units-vs-credits/</guid>
      <description>&lt;p&gt;Ethereum RPC pricing is harder to compare than it looks. Two providers can advertise similar headline numbers and still bill you wildly differently, because the unit being counted is not the same. This post breaks down the pricing models you will actually meet, shows how to estimate a monthly bill for each, and explains where a bundled-credit plan fits. Provider plans and weights change frequently; treat the numbers here as a qualitative snapshot as of June 2026 and confirm against official docs before you commit.&lt;/p&gt;</description>
    </item>
    <item>
      <title>What &#34;missing trie node&#34; Means and Why You Need an Archive Node</title>
      <link>https://blazed.sh/blog/posts/missing-trie-node/</link>
      <pubDate>Tue, 23 Jun 2026 10:00:00 +0000</pubDate>
      <guid>https://blazed.sh/blog/posts/missing-trie-node/</guid>
      <description>&lt;p&gt;You ran a query against a slightly older block, and instead of an answer you got this:&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;missing trie node 2bca...e91f (path ) state 0x2bca...e91f is not available&#xA;&lt;/span&gt;&lt;/span&gt;&lt;/code&gt;&lt;/pre&gt;&lt;/div&gt;&lt;p&gt;Or a nearby historical-query failure such as:&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;header not found&#xA;&lt;/span&gt;&lt;/span&gt;&lt;/code&gt;&lt;/pre&gt;&lt;/div&gt;&lt;p&gt;&lt;code&gt;missing trie node&lt;/code&gt; specifically means the state needed to answer your query is unavailable. &lt;code&gt;header not found&lt;/code&gt; can also come from a bad block reference, an unsynced endpoint, or provider retention behavior, so treat it as a related symptom rather than the exact same error. This post explains what the state trie is, why a full node prunes it, exactly when you will trip missing historical state, and how to fix it; at the end we look at why an archive node, ideally one you do not have to operate, is the only real cure.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Why MEV Is a Latency Game: The Case for Co-located Ethereum Nodes</title>
      <link>https://blazed.sh/blog/posts/mev-latency-colocated-ethereum-nodes/</link>
      <pubDate>Tue, 23 Jun 2026 09:00:00 +0000</pubDate>
      <guid>https://blazed.sh/blog/posts/mev-latency-colocated-ethereum-nodes/</guid>
      <description>&lt;p&gt;Most write-ups about MEV focus on strategy: arbitrage, liquidations, sandwiching, backruns. Strategy is necessary, but it is not what separates a profitable searcher from a spectator. The deciding factor is usually time. By the time a pending transaction reaches you over a public RPC gateway, has been parsed, evaluated, and answered with a fresh state read across the network, the opportunity may already belong to someone closer to the chain. This post is about where those milliseconds go and how co-located node access closes the gap.&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>
    <item>
      <title>Building Real-Time Ethereum Event Notifications with BLAZED.sh</title>
      <link>https://blazed.sh/blog/posts/ethereum-webhook-tool-blazed/</link>
      <pubDate>Mon, 25 Aug 2025 14:00:00 +0000</pubDate>
      <guid>https://blazed.sh/blog/posts/ethereum-webhook-tool-blazed/</guid>
      <description>&lt;p&gt;Applications that react to blockchain events in real time need low-latency infrastructure, especially when dealing with event filters that return large datasets (liquidation monitors, DEX aggregators, cross-chain bridges).&lt;/p&gt;&#xA;&lt;p&gt;In this tutorial, we&amp;rsquo;ll build a webhook service that monitors Ethereum events and sends notifications to configured URLs, using BLAZED.sh&amp;rsquo;s co-located Ethereum node access for a local path to chain data.&lt;/p&gt;&#xA;&lt;h2 id=&#34;understanding-blazedshs-architecture&#34;&gt;Understanding BLAZED.sh&amp;rsquo;s Architecture&lt;/h2&gt;&#xA;&lt;p&gt;BLAZED.sh is optimized for Ethereum applications that require consistent low latency and predictable costs. Instead of calling a remote gateway across the public internet, your service runs on the same host as a fully synced Ethereum node and connects today over the node&amp;rsquo;s local WebSocket endpoint (&lt;code&gt;ws://eth:8545&lt;/code&gt;).&lt;/p&gt;</description>
    </item>
  </channel>
</rss>
