<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Blockchain on Antomor</title><link>https://antomor.com/categories/blockchain/</link><description>Recent content in Blockchain on Antomor</description><generator>Hugo -- gohugo.io</generator><language>en</language><managingEditor>dev@antomor.com (Antonio Morrone)</managingEditor><webMaster>dev@antomor.com (Antonio Morrone)</webMaster><copyright>© 2026 Antonio Morrone</copyright><lastBuildDate>Mon, 22 Jun 2026 10:00:00 +0200</lastBuildDate><atom:link href="https://antomor.com/categories/blockchain/index.xml" rel="self" type="application/rss+xml"/><item><title>Reorgs, Retries, and Race Conditions: Building a Bitcoin-Watching Off-Chain Service</title><link>https://antomor.com/blog/bitcoin-watchdog-reorgs-race-conditions/</link><pubDate>Mon, 22 Jun 2026 10:00:00 +0200</pubDate><author>dev@antomor.com (Antonio Morrone)</author><guid>https://antomor.com/blog/bitcoin-watchdog-reorgs-race-conditions/</guid><description>&lt;p&gt;I worked on a production off-chain service: a system that watches Bitcoin activity and coordinates downstream operations on Ethereum for a cross-chain interoperability system, with more than one independent operator watching and acting on the same chain activity. It&amp;rsquo;s a monitoring and coordination role, not custody or key management: the service observes Bitcoin, decides what that activity means, and triggers the corresponding action elsewhere. Getting that decision right, without producing duplicate downstream effects, in the face of a chain that can change its mind, turns out to be most of the engineering problem.&lt;/p&gt;</description></item><item><title>From EVM Events to Reliable Application State with Ponder</title><link>https://antomor.com/blog/indexing-onchain-events-with-ponder/</link><pubDate>Tue, 14 Apr 2026 10:00:00 +0200</pubDate><author>dev@antomor.com (Antonio Morrone)</author><guid>https://antomor.com/blog/indexing-onchain-events-with-ponder/</guid><description>&lt;p&gt;A chain doesn&amp;rsquo;t hand you application state, it hands you a stream of events with a footnote attached: this stream can be revised. &lt;a href="https://ponder.sh/" target="_blank" rel="noreferrer"&gt;Ponder&lt;/a&gt; is one good vehicle for turning that stream into state you can actually query and trust, but the tool is secondary to the problem. This post is mostly about the problem.&lt;/p&gt;&#10;&#10;&lt;h2 class="relative group"&gt;The problem&#10; &lt;div id="the-problem" class="anchor"&gt;&lt;/div&gt;&#10; &#10; &lt;span&#10; class="absolute top-0 w-6 transition-opacity opacity-0 -start-6 not-prose group-hover:opacity-100 select-none"&gt;&#10; &lt;a class="text-primary-300 dark:text-neutral-700 !no-underline" href="#the-problem" aria-label="Anchor"&gt;#&lt;/a&gt;&#10; &lt;/span&gt;&#10; &#10;&lt;/h2&gt;&#10;&lt;p&gt;A block your service already processed can stop being canonical. An RPC node can tell you two different things about the same height five minutes apart. An application built to read &amp;ldquo;current state&amp;rdquo; directly off the chain on every request has no principled way to handle any of that; it just re-derives an answer each time and hopes the chain agrees with itself in the meantime.&lt;/p&gt;</description></item><item><title>Understanding Vault Standards: EIP-4626 and Beyond</title><link>https://antomor.com/blog/understanding-vault-standards-eip-4626-and-beyond/</link><pubDate>Wed, 20 Aug 2025 11:00:00 +0200</pubDate><author>dev@antomor.com (Antonio Morrone)</author><guid>https://antomor.com/blog/understanding-vault-standards-eip-4626-and-beyond/</guid><description>&lt;p&gt;While researching vault standards to inform the design of a planned vault product on Rootstock, it became clear pretty quickly that &amp;ldquo;use ERC-4626&amp;rdquo; wasn&amp;rsquo;t the whole answer. The base standard covers a lot, but it also assumes a specific shape (one share token, one asset, everything settling synchronously) that doesn&amp;rsquo;t fit every vault a real product might need. I put together an internal walkthrough for the team, covering ERC-4626 and the standards that extend it, for exactly the cases where the base spec runs out. This post is that walkthrough.&lt;/p&gt;</description></item><item><title>Cutting RPC Calls by 90%: Building an On-Chain Indexing Layer</title><link>https://antomor.com/blog/onchain-indexing-layer-rpc-reduction/</link><pubDate>Wed, 12 Mar 2025 11:00:00 +0100</pubDate><author>dev@antomor.com (Antonio Morrone)</author><guid>https://antomor.com/blog/onchain-indexing-layer-rpc-reduction/</guid><description>&lt;p&gt;At RootstockLabs, one of the products I owned the architecture for was the &lt;a href="https://app.rootstockcollective.xyz/" target="_blank" rel="noreferrer"&gt;RootstockCollective dApp&lt;/a&gt; (&lt;a href="https://github.com/RootstockCollective/dao-frontend" target="_blank" rel="noreferrer"&gt;frontend source&lt;/a&gt;) — a UI that needs to answer questions like &amp;ldquo;what&amp;rsquo;s this user&amp;rsquo;s balance,&amp;rdquo; &amp;ldquo;what has this contract emitted since block X,&amp;rdquo; and &amp;ldquo;show me the history of this account&amp;rdquo; on every page load. This is the story of how that UI went from asking the chain those questions directly, every time, to asking a decentralized indexing network instead — and why the process mattered as much as the destination.&lt;/p&gt;</description></item><item><title>Engineering Gasless Transactions: Smart Wallets, Meta-Transactions and the Boltz Integration</title><link>https://antomor.com/blog/engineering-gasless-transactions-boltz-integration/</link><pubDate>Wed, 20 Nov 2024 10:00:00 +0100</pubDate><author>dev@antomor.com (Antonio Morrone)</author><guid>https://antomor.com/blog/engineering-gasless-transactions-boltz-integration/</guid><description>&lt;p&gt;A new user shows up with an address and no RBTC in it. Every transaction, including the very first one, needs gas, and gas on Rootstock is paid in RBTC. &lt;a href="https://github.com/rsksmart/rif-relay" target="_blank" rel="noreferrer"&gt;RIF Relay&lt;/a&gt; removes that requirement: a user pays with a token they already hold, or gets the transaction sponsored outright, while a separate account submits it and pays the actual gas.&lt;/p&gt;&#10;&lt;p&gt;At RootstockLabs, I led the team that extended and productionized RIF Relay, including the smart-contract changes required to support &lt;a href="https://boltz.exchange/" target="_blank" rel="noreferrer"&gt;Boltz&lt;/a&gt;&amp;rsquo;s Rootstock integration, a non-custodial Bitcoin and Lightning swap service. This post covers how RIF Relay&amp;rsquo;s relay flow and smart-wallet architecture work, and what changed when a real integration stopped fitting the generic model.&lt;/p&gt;</description></item></channel></rss>