Assessing the Systemic Risks of Bitcoin Metaprotocols on Network Stability and Institutional Custody

Executive Summary

This report’s central thesis is that Bitcoin metaprotocols (Ordinals and Runes) introduce hazardous, application-layer vulnerabilities. These vulnerabilities pose a direct systemic risk to the operational and settlement finality of institutional Bitcoin products, including Spot ETFs.

This report assesses the systemic risks from Bitcoin metaprotocols, specifically Ordinals and Runes. It analyzes their impact on the stability of the Bitcoin network and the operational security of institutional financial products. These products include Spot Bitcoin ETFs and large corporate treasury accumulators like “Strategy Inc.” (formerly MicroStrategy).

Key Findings:

1. Protocols Are Live: Both Ordinals (January 2023) ¹ and Runes (April 2024) ³ are fully active on the Bitcoin mainnet. Their impact is not hypothetical. The Runes launch immediately caused record-high network congestion and transaction fees.⁴
2. Core Vulnerability: The primary risk stems from a combination of two factors. The first is the Runes protocol’s “cenotaph” (token-burning) mechanic.⁷ The second is its complete dependency on a fragmented ecosystem of second-layer “indexers” (e.g., UniSat, Hiro).¹⁰
3. The “Cascade” Scenario: The report outlines an “Alpha-to-Omega” attack playbook. The core trigger is a “chain reorganization” (reorg)—a normal ¹² or maliciously-induced ¹³ event where the blockchain tip is briefly rolled back. This event can cause different indexers to desynchronize, an event we term “indexer churn”.¹⁵ This churn can incorrectly flag valid user transactions as “cenotaphs,” leading to the irreversible burning of users’ tokens.⁹ This, in turn, is designed to trigger a panic-driven “retry storm”.¹⁷ Thousands of users would flood the network with high-fee Replace-By-Fee (RBF) transactions, creating a mempool feedback loop and catastrophic fee spikes.
4. Institutional Collision (ETFs): This manufactured “congestion tax” poses a direct threat to Spot Bitcoin ETFs. The market’s custodians are highly concentrated (9 of 12 U.S. ETFs use Coinbase).¹⁸ During a cascade, these custodians may be forced to execute essential, high-input “cold storage rotations” to meet redemption requests. As explicitly disclosed in their own prospectuses ²¹, the extreme fees or network delays could force them to halt redemptions. This would trigger a market-wide liquidity crisis.
5. Institutional Collision (Strategy Inc.): The same “congestion tax” directly attacks the business model of corporate accumulators.²³ Strategy Inc. would be forced to choose between paying exorbitant, multi-BTC fees (see Table 3) for routine custody transfers ²⁴ or accepting catastrophic counterparty risk by leaving billions in assets on an exchange during the network storm.
6. Attack Amplifiers: This vulnerability is amplified by two external factors: (1) An ideological “civil war” among Bitcoin developers over “spam filtering” ²⁵, which has led to policy fragmentation (e.g., Core v30 vs. Knots ²⁷), creating “non-relay zones” that break fee-bumping. (2) The proven feasibility of network-layer BGP Hijacks and Eclipse Attacks ¹³ to deliberately induce the reorgs that trigger the entire cascade.

Conclusion:

Ordinals and Runes do not introduce a consensus flaw to Bitcoin. However, they have successfully created a financialized denial-of-service (DoS) vector. They weaponize the fee market, imposing a direct, punitive “congestion tax” on all other network participants. This poses a direct, quantifiable, and systemic risk to the operational and settlement finality of the institutional financial products built atop the network.

Section I: Protocol and Claims Investigation

This section deconstructs the subject protocols themselves. Before assessing the risk, we must first establish the mechanics: who created these protocols, why they exist, how they function on-chain, and how their core design creates the initial vulnerabilities.

A. Dossier on Ordinals and Runes: Foundational Intelligence (Who, What, Why, How, When)

A critical analysis of the subject protocols must begin with their origin and intent. Both Ordinals and Runes were created by Bitcoin developer Casey Rodarmor.²⁹ Rodarmor has publicly expressed frustration with the complexity of other blockchains, notably describing Ethereum as a “Rube Goldberg machine”.³¹ This preference for simplicity informs the design of his Bitcoin-based protocols.

The “Why” is essential. Rodarmor’s creation of the Ordinals protocol inadvertently enabled the development of the BRC-20 token standard. This was a protocol he criticized for creating inefficient “junk” Unspent Transaction Outputs (UTXOs).³²

While Rodarmor views 99.9% of fungible tokens as “scams and memes,” he acknowledges they “don’t appear to be going away”.³² Consequently, he developed Runes as a competing protocol. It is explicitly designed as a “harm reduction” measure. Runes aims to be a more efficient, UTXO-based alternative to mitigate the network bloat and congestion caused by BRC-20s.³²

The “What” and “How” define the technical conflict:

• Ordinals: This protocol facilitates non-fungible tokens (NFTs) on Bitcoin.³⁶ It functions by “inscribing” arbitrary data, like images or text, onto individual satoshis (the smallest unit of Bitcoin).³⁶ Technically, this data is stored in the Taproot witness data of a transaction.³⁴ Ordinals have been live on the Bitcoin mainnet since January 2023.¹
• Runes: This protocol is for fungible tokens, such as memecoins or loyalty points.³⁶ Unlike Ordinals, Runes encodes its messages (the “runestone”) into a single, prunable OP_RETURN output.³⁴ This design is intended to be more efficient. It leaves a lighter footprint on Bitcoin’s critical UTXO set (the global database of all spendable bitcoin “coins”).³⁴ Runes went live on the Bitcoin mainnet in April 2024. This launch was timed precisely with the block subsidy halving at block 840,000.²

Both protocols were vetted on Bitcoin’s testnets. For instance, the Xverse wallet integrated Runes testnet support prior to the mainnet launch.⁴¹

The user’s query (“whether any… have officially taken effect”) is thus definitively answered: Yes, both protocols are fully live and active on the Bitcoin mainnet today.

The potential for “toxicity” is not a future hypothetical. The Runes launch in April 2024 provides a direct historical precedent. It immediately triggered a massive surge in network activity and record-high transaction fees. Average fees surged to over $128 as users rushed to mint new tokens, demonstrating the protocol’s capacity to induce “mempool mania”.⁴

Rodarmor’s “harm reduction” motive is a tacit admission from the creator that these metaprotocols introduce significant negative externalities like congestion and data bloat. The design of Runes is an attempt to manage this self-inflicted damage. It does so by shifting the “spam” from the witness data to the OP_RETURN data.

B. Core Mechanic Analysis: The “Cenotaph” Exploit Vector

The Runes protocol includes a unique and critical mechanic known as a “cenotaph.” A cenotaph is a “runestone” (the OP_RETURN data payload) that an indexer deems malformed or invalid.⁷ This invalidation can occur for various reasons, such as an incorrect data encoding or a violation of the protocol’s minting rules.⁷

This mechanic functions as a deliberate, “fail-closed” design. If an indexer finds a cenotaph in a transaction, the consequences are severe and irreversible:

1. The attempted transaction (e.g., a mint or transfer) fails.⁴⁴
2. All runes input to this transaction are permanently “burned” and destroyed.⁷
3. If the transaction was a mint attempt, that failed mint still counts toward the rune’s total supply cap. The tokens themselves, however, are burned instead of being created.⁴³

The stated purpose for this harsh mechanic is to serve as an “upgrade mechanism”.⁴⁴ It allows developers to alter the Runes protocol rules in the future.

Clients (indexers) that have not upgraded will not “misunderstand” new rules. They will simply interpret the new-style transactions as malformed (cenotaphs). They will then correctly register the runes as burned. This design prioritizes protocol-level consistency over safeguarding an individual user’s funds.⁷

This design, however, creates a potent, weaponized vulnerability. The “validity” of a runestone is not determined by Bitcoin’s core consensus rules, which are global and unambiguous. Instead, it is a matter of interpretation by third-party “indexer” software.

An attacker, therefore, does not need to break Bitcoin consensus. They merely need to create a situation where different indexers disagree on the validity of a runestone.

If Indexer A (e.g., used by UniSat) interprets a transaction as “Valid,” while Indexer B (e.g., used by Hiro) interprets it as a “Cenotaph” ⁸, a user’s wallet polling Indexer B will suddenly show a “failed mint” and “burned tokens.” This user, most likely believing their transaction simply failed due to network congestion (not an irreversible protocol-level burn), will predictably panic. They will then attempt to retry the transaction, often using Replace-By-Fee (RBF) with a much higher fee.¹⁷

The cenotaph mechanic, intended to enforce “meticulous” UTXO management ⁷, thus becomes the very trigger for a user-panic-driven “thundering herd” attack on the mempool.

C. The Indexer Dependency: A Network Vulnerability Outside Consensus

The cenotaph vulnerability is amplified by the fundamental architecture of all Bitcoin metaprotocols. Standard Bitcoin Core nodes do not understand Ordinals or Runes; they see only transaction data.

These protocols require a separate, second layer of “indexer” software. Examples include the open-source ord client, UniSat’s indexer, or Hiro’s “Ordhook” and “Runehook”.¹⁰ These indexers scan the Bitcoin blockchain. They interpret the specialized data in witness fields or OP_RETURN outputs. Then, they maintain their own “stateful” database of who owns which metaprotocol asset.¹¹ Wallets and marketplaces query these indexers via APIs to display balances and validate transactions.

This architecture has a critical dependency: Bitcoin’s blockchain is not perfectly linear. Small “chain reorganizations” (reorgs) are a normal, albeit infrequent, part of Bitcoin’s consensus mechanism.⁵⁰ A reorg occurs when the last one or two blocks are “orphaned” and replaced by a competing, longer chain.

When a reorg occurs, these application-layer indexers must also roll back their internal databases. They must re-scan the new canonical chain to reflect the correct state.¹⁵ This is a complex and error-prone process. A Bitcoin node itself may only re-validate and re-add transactions from a reorg up to a certain depth (e.g., 10 blocks) before simply dropping them.⁵²

This creates the “indexer churn” vulnerability. The risk is indexer divergence during the reorg and rollback process. This can happen for several reasons:

• Latency: Different indexer providers (e.g., UniSat, Hiro) may detect and process the reorg at different speeds.¹⁰
• Divergent Logic: They may have different bugs or business logic for handling the complex state rollback.¹⁵
• Propagation: Nodes on the P2P network receive new blocks at slightly different times. This leads to transient, different views of the chain tip.⁵³

This leads directly to the “Cenotaph/Reorg Collision,” the primary trigger for a cascade:

1. Event: A 2-block reorg occurs.¹²
2. Action: All Runes indexers (Hiro, UniSat, etc.) begin to roll back their state.¹⁶
3. State of Confusion: For several minutes, these indexers are out of sync. A user’s wallet querying Hiro’s API ¹⁰ might show a different balance than a wallet querying UniSat’s API.
4. The Collision: A user’s retry transaction (from an initial “churn” failure) is re-broadcast into this post-reorg mempool.
5. The Result: An indexer, having now processed the reorg, sees this retry as invalid (e.g., “mint cap is now full” on the new chain). It flags the transaction as a cenotaph, instantly burning the user’s funds.⁹
6. The Cascade: The user sees a second failure, this time with a financial loss, and panics again. Influencers on social media declare the “mint failed.” This triggers a mass retry storm ¹⁷ from thousands of users. These users all fight for the same blockspace, all use RBF, and all compete directly with high-priority institutional transactions.

Section II: Institutional and Financial Risk Analysis

With the technical vulnerabilities established, this section analyzes the direct financial and operational impact on institutional stakeholders. The analysis moves from protocol theory to market reality. It focuses on the specific custody and settlement procedures of ETFs and corporate accumulators and their explicitly documented weaknesses.

A. ETF Custody Operations: The Stakeholders

The risk of such a cascade is not isolated to retail users. It poses a direct, systemic threat to the institutional financial products built on Bitcoin. This threat is magnified by the extreme custodian concentration in the U.S. Spot Bitcoin ETF market.¹⁸

The primary custodians for the major U.S. ETFs are:

• Coinbase Custody Trust: Serves as the custodian for the vast majority of the market. Clients include BlackRock (IBIT), ARK 21Shares (ARKB), Bitwise (BITB), and Valkyrie (BRRR, as co-custodian). In total, 9 of the 12 approved ETFs utilize Coinbase.¹⁸
• Gemini Trust: Serves as the custodian for the VanEck Bitcoin Trust (HODL).¹⁸
• Fidelity Digital Assets: Employs a self-custody model for its own Fidelity Wise Origin Bitcoin Fund (FBTC).¹⁸
• BitGo: Acts as a co-custodian for Valkyrie (BRRR).¹⁸

This concentration means that any operational failure or congestion-induced issue at Coinbase Custody is not an isolated event. It represents a systemic, single point of failure for the overwhelming majority of the U.S. Spot Bitcoin ETF market.

A failure by Coinbase’s systems to manage UTXOs or broadcast fee-bumps during a cascade could directly threaten settlement finality for nearly the entire asset class. This risks a market-wide crisis of confidence. Fidelity’s vertically-integrated, self-custody model ²⁰ makes it the only major provider structurally resilient to this specific single-point-of-failure.

B. Custody Failover and Settlement Risk (The “Omega” Collision)

The precise mechanism of failure is found in the operational procedures of these custodians. Institutional custody relies on “deep cold storage.” This means offline, air-gapped hardware wallets or paper keys stored in geographically-distributed, high-security vaults.⁵⁵

Access to these funds is controlled not by a single key, but by Multisignature (multisig) (e.g., 2-of-3) or Multi-Party Computation (MPC) protocols. These require a formal, multi-person key-signing ceremony.⁵⁵

To avoid this friction for daily flows, custodians maintain a small amount of Bitcoin in a “Trading Balance”—a hot or warm wallet—to service routine creations and redemptions.²¹ The “cold storage rotation” is the high-stakes process of moving funds from a deep cold vault to replenish this Trading Balance.⁵⁷

This operational model is the point of failure. The risk is not speculative. It is explicitly disclosed in the ETFs’ own public prospectuses:

• BlackRock (IBIT) Prospectus (S-1): Warns of multiple risk factors ²¹:”Bitcoin transactions… are susceptible to delays due to… network outage, congestion, spikes in transaction fees… Disruption… at the… Bitcoin Custodian would have the potential to delay settlement of the bitcoin related to Share redemptions.”
• Other Filings: Echo this concern ²²:”Increased transaction volume could result in delays in the recording of transactions due to congestion in the Bitcoin Network.”

This “prospectus warning” outlines the collision scenario:

1. An ETF (e.g., IBIT) normally handles daily redemptions from its hot “Trading Balance”.²¹
2. A large, persistent net-redemption flow (e.g., due to market panic) depletes this hot wallet.
3. The custodian (Coinbase) must now perform a “cold storage rotation” to meet its settlement obligations.⁵⁷ This is a large, complex, high-input-count transaction.
4. This must-confirm institutional transaction is broadcast precisely as the Runes-driven mempool cascade reaches its peak. Fees are at 1,000+ sat/vB.⁶⁰
5. The custodian now faces two choices:a) Pay an exorbitant fee to get the transaction included in the next block. This could cost hundreds of thousands of dollars (see Section IV.B).b) Fail to settle. Activate the prospectus clause 21 and halt redemptions, citing “network congestion.”
6. A halt in redemptions on a flagship ETF like IBIT, even if temporary, would be a catastrophic market event. It would shatter investor confidence and trigger a severe deviation between the ETF’s share price and its Net Asset Value (NAV).

C. Corporate Accumulator Hazard: “Strategy Inc.” (formerly MicroStrategy)

The operational risk extends to large corporate accumulators, most notably “Strategy Inc.” (formerly MicroStrategy). Strategy Inc.’s primary business model is to use capital markets (issuing debt and equity) to acquire and hold Bitcoin as a treasury asset.⁶¹

Like the ETFs, Strategy Inc.’s own 10-K filings explicitly identify “transaction congestion and fees associated with processing transactions on the Bitcoin network” as a material risk to its business.²³

Strategy Inc.’s vulnerability is distinct from but parallel to that of the ETFs. While an ETF reacts to investor flows, Strategy Inc.’s model is proactive accumulation.⁶³ A core, non-negotiable business operation is the periodic purchase of large amounts of Bitcoin. This Bitcoin must then be moved on-chain from an exchange to their own institutional cold storage (likely managed by a custodian like BitGo or Coinbase).⁶⁴

A Runes-driven fee mania ⁴ thus acts as a direct, punitive “congestion tax” on Strategy Inc.’s core business model.⁶⁵ During a multi-day backlog ⁶⁶, Strategy Inc.’s treasury team faces a critical dilemma:

1. Pay the Tax: Execute their custody transfer at a peak fee of 1,000+ sat/vB. This turns a routine operational transfer into a massive, unbudgeted capital expense.
2. Accept Counterparty Risk: Leave their newly-purchased assets (often valued in the hundreds of millions or billions of dollars) on the exchange for days or weeks while waiting for the mempool to clear. This exposes the company to catastrophic loss if that exchange counterparty fails in the interim.

The “spam” from Runes is, therefore, not a mere nuisance. It is a direct financial attack on the operational and economic viability of Strategy Inc.’s (and any other corporate accumulator’s) treasury model.

Section III: External Influences and Network Attack Vectors

The risks inherent in the protocols are amplified by external human and network factors. This section investigates two key accelerators. The first is the ideological “civil war” within the developer community that is fragmenting the network’s relay policies. The second is the proven-yet-underestimated threat of network-layer routing attacks that can be used to trigger a cascade on command.

A. The Bitcoin Developer “Civil War”: Policy vs. Consensus

The underlying mempool volatility is exacerbated by a deep, ideological “civil war” within the Bitcoin developer community.²⁵ This conflict is over the metaprotocols themselves.

• Camp 1 (Anti-Spam): This camp is led by figures like longtime developer Luke Dashjr. They view Ordinals and Runes as “spam,” a “bug,” or a “5-vector attack” on Bitcoin’s primary function as a monetary network.⁶⁸
• Camp 2 (Pro-Permissionless): This camp argues that Bitcoin is a permissionless blockspace market. They believe any transaction that pays the required fee is valid, regardless of its data content. In their view, “fees are the governor” and any filtering is a form of censorship.⁷¹

This ideological battle is not fought at the consensus level (what makes a block valid). It is fought at the mempool relay policy level (what transactions an individual node agrees to relay to its peers).⁷¹ This has led both sides to create “weapons”:

1. Anti-Ordinal Filters: Dashjr and others developed the “Ordisrespector” patch ⁷⁴ and the Bitcoin Knots client.²⁶ This alternative node software actively filters and rejects Ordinals/Runes transactions, refusing to relay them.
2. Miner-Level Filtering: The OCEAN mining pool (associated with Dashjr) implemented this logic. It offered block templates to its miners that excluded this “spam” and prioritized “real” financial transactions.⁷⁵
3. Pro-Ordinal Policy (Core v30): In response, Bitcoin Core developers merged a controversial change for the v30 release (Oct 2024). This “harm reduction” change massively increases the default OP_RETURN relay limit from ~80 bytes to 100,000 bytes.⁷²

The rationale for the Core v30 change ²⁸ is that “spammers” were already bypassing the 80-byte limit. They were stuffing data into the more harmful and non-prunable witness/UTXO space. By relaxing the OP_RETURN limit, developers hope to incentivize spammers to use the less harmful, prunable OP_RETURN space instead.⁷²

This “civil war” creates a new attack vector: policy fragmentation. The Bitcoin network is no longer a monoculture running default Bitcoin Core. It is a fragmented ecosystem of Core v30, older Core versions, Knots ²⁷, and “Ordisrespector” nodes.⁷⁴

An attacker can exploit this. They can broadcast a transaction that Core v30 nodes accept and relay ²⁸ but that Knots nodes reject and drop.²⁷ This creates “policy islands” and “non-relay zones”.⁷⁵

This fragmentation is what creates “non-relay zones.” A custodian’s node, for example, may broadcast a high-fee RBF (Replace-By-Fee) transaction. But that transaction is immediately dropped by any “anti-spam” peers (like Knots) it connects to. Because those peers refuse to relay it, the RBF transaction never reaches the miners who are also running the “anti-spam” filter. This effectively creates a “black hole” on the network for that specific transaction and renders the fee-bump ineffective.

B. Routing Attacks as a Cascade Trigger (The “Delta” Twist)

The most sophisticated attack vector combines application-layer exploits with network-layer attacks on the internet’s core infrastructure. Both BGP hijacking and Eclipse attacks have been academically demonstrated as practical and effective against the Bitcoin network.⁷⁸

• BGP Hijacking: An adversary (e.g., a malicious ISP) can falsely advertise IP prefixes to re-route internet traffic.⁷⁸ Due to the high centralization of mining power, research indicates that hijacking fewer than 100 BGP prefixes could partition approximately 50% of the Bitcoin mining network.¹³ This attack can isolate large portions of the network and “considerably slow down block propagation”.¹³
• Eclipse Attack: This is a more targeted attack. An adversary monopolizes all peer-to-peer (P2P) connections to a single victim node, such as a custodian’s or miner’s node. This effectively isolates it from the true network and feeds it false data.⁸³

The primary consequence of both attacks is that they directly and deliberately increase the probability of block reorgs, also known as “adversarial forks”.¹⁴

This forms the “BGP-Reorg-Cenotaph” attack chain. An attacker does not need to wait for a random reorg to trigger the “Cenotaph/Reorg Collision” (Section I.C). They can induce one on command.

1. The attacker first stresses the mempool with a Runes mint (Beta and Gamma phases).
2. At the peak of the confusion, they launch a targeted BGP hijack ¹³ against the Autonomous Systems (ASNs) hosting major mining pools.
3. This partitions the network, causing miners in different partitions to mine competing blocks. This forces a 1-2 block reorg as the network eventually re-converges.
4. This forced reorg is the “Delta” trigger. It forces a mass rollback of all Runes indexers ¹⁶, triggering the mass-cenotaph burn event ⁹ and subsequent user-panic feedback loop.
5. This combined attack creates a perfect storm. User panic drives infinite RBF retries. Network fragmentation (both physical ⁸⁷ and policy-based ⁷⁵) prevents fee bumps from propagating. And institutional custodians must pay any price to get their settlement transactions through the bottleneck.

Section IV: Black Swan Scenario Modeling

This section synthesizes the preceding components into a comprehensive “Alpha-to-Omega” attack playbook. It provides a concrete, step-by-step scenario of an advanced adversarial attack and quantifies the financial cost of its impact. The components are the protocol exploit (cenotaphs), institutional fragility (custody), and external triggers (policy fragmentation and BGP attacks).

A. The “Alpha-to-Omega” Adversarial Playbook (Synthesized)

The components combine into a coherent, multi-stage attack playbook:

• Alpha (Setup): The adversary identifies a popular, supply-capped Runes mint. They prepare “borderline” runestone payloads designed to create indexer disagreements.⁴⁴ They also prepare Partially Signed Bitcoin Transactions (PSBTs) to execute “snipping” attacks—a form of front-running—to outbid legitimate minters.³⁸
• Beta (Fee Shock): As the mint launches, the adversary floods the mempool with their “snipping” transactions and ambiguous payloads. Simultaneously, they broadcast low-fee “clogger” transactions with complex ancestor/descendant chains to fill mempool slots.⁹⁰ Legitimate users find their transactions “stuck” and begin using RBF.¹⁷ The mempool’s minimum fee (mempoolminfee) begins to rise.
• Gamma (Indexer Churn): The attacker’s “snipping” ⁸⁸ and “borderline” transactions cause initial mint failures. Wallets polling different APIs (e.g., UniSat vs. Hiro) ¹⁰ show conflicting results. Some users see “minted,” while others see “failed” or a “cenotaph” burn.⁸ This divergence triggers the first wave of panic-driven “retry storms.”
• Delta (Reorg Twist): At the height of the user-panic, the attacker executes the network-layer attack: a BGP hijack or Eclipse attack ¹³ targeting major mining pools. This induces a 1-2 block reorg. This event is publicly verifiable on monitoring tools like ForkMonitor.info.⁹¹
• Omega (Feedback Loop): The forced reorg triggers the mass-vulnerability. All Runes indexers are forced to roll back their state.¹⁶ This mass-rollback instantly invalidates thousands of in-flight user retry transactions (e.g., the mint cap is now filled on the new chain tip), flagging them as cenotaphs.⁹ A mass-burn event occurs. This triggers a final, global panic-retry wave. This wave, characterized by 2,000+ sat/vB fees, collides directly with:
  1. ETF Custodians ²⁰ attempting to execute a cold-storage rotation to meet redemption requests.²¹
  2. “Strategy Inc.” ⁶² attempting to move its latest $100M+ BTC purchase to secure custody.²³
  3. Lightning Network operators attempting to open/close channels to manage liquidity.

All these “must-confirm” financial transactions are now forced to pay the attacker-induced peak fee. This results in catastrophic operational costs or outright settlement failures.

B. Quantifying the Pain: Cost Modeling and Correlated Risks

The financial impact of this “congestion tax” can be modeled. Historical precedent from the 2023 BRC-20 manias and the 2024 Runes launch shows that mempool backlogs for low-fee transactions can last for days or even weeks.⁶⁶

Fee spikes during these events are extreme. The April 2024 Runes launch saw record fees, averaging $128 ⁴ and, according to mempool observers, briefly peaking at rates exceeding 2,700 sat/vB.⁶ This dwarfs the 2017 record of ~1,100 sat/vB.⁶⁰

The primary victims of these fees are high-input-count “consolidation” transactions. These are operationally essential for custodians, exchanges, and large accumulators like Strategy Inc. to manage their UTXOs.93 The virtual byte (vbyte) size of a modern P2WPKH (SegWit) transaction with $N$ inputs and 1 output can be approximated by the formula:

$Total \ vbytes \approx 41.5 + N \times 68.25$.24

Using this model, the cost of a single essential operational transaction during a peak cascade event becomes astronomical.

Table 3: Consolidation Transaction Cost Model (P2WPKH Inputs)

Purpose: To provide a concrete financial model for the cost of a single “must-confirm” operational transaction (e.g., an ETF redemption or Strategy Inc. custody-transfer) during a peak cascade.

Number of Inputs (N)	Est. vBytes	Cost at 200 sat/vB (sats)	Cost at 1,000 sat/vB (sats)	Cost at 2,700 sat/vB (sats)
10	~724 vB	144,800 sats (0.0014 BTC)	724,000 sats (0.0072 BTC)	1,954,800 sats (0.0195 BTC)
100	~6,867 vB	1,373,400 sats (0.0137 BTC)	6,867,000 sats (0.0687 BTC)	18,540,900 sats (0.1854 BTC)
500	~34,167 vB	6,833,400 sats (0.0683 BTC)	34,167,000 sats (0.3417 BTC)	92,250,900 sats (0.9225 BTC)
1,000	~68,292 vB	13,658,400 sats (0.1366 BTC)	68,292,000 sats (0.6829 BTC)	184,388,400 sats (1.8439 BTC)

This analysis is compounded by a correlated risk: stablecoin de-pegging. During a market-wide panic (such as a major ETF halting redemptions), liquidity will flee to safety. This could trigger a “run” on stablecoin reserves.

This is not hypothetical. USDC (Circle), which was exposed to Silicon Valley Bank, de-pegged to ~$0.87 in March 2023.⁹⁶ USDT (Tether) has also experienced multiple brief de-pegs.⁹⁸

An operations team at a firm like Strategy Inc. is thus doubly compromised. They calculate their fee liability in BTC (as per Table 3), but their debt and operational liabilities are in USD.⁶¹ If they must source USD during the cascade, they cannot rely on a 1:1 stablecoin peg.⁹⁹ They risk paying 1.84 BTC in on-chain fees and simultaneously realizing a 13% loss on their stablecoin reserves. This creates a perfect operational storm.¹⁰⁰

C. High-Risk Calendar: Identifying “Quad-Witching” Collision Windows

An adversary can maximize damage by timing a Runes-driven mempool spike to collide with periods of guaranteed high institutional on-chain movement. Operations teams must treat these windows as periods of maximum fragility.

Table 4: High-Risk Calendar: Mempool/Institutional Collision Points

Purpose: To provide a forward-looking, actionable calendar of the most dangerous days for operations teams to plan around.

Event	Frequency / 2025 Dates	Risk Type	Rationale & Collision Scenario
CME Bitcoin Futures Expiry	Last Friday of each month. (e.g., Mar 28, Jun 27, Sep 26, Dec 26, 2025) [101, 102]	TradFi / Arbitrage	Drives high-volume on-chain flows from arbitrageurs and hedgers settling/rolling positions. A mempool spike on this day collides with time-sensitive arb flow.
“Quad Witching”	3rd Friday of Mar, Jun, Sep, Dec. (e.g., Mar 21, Jun 20, Sep 19, Dec 19, 2025) [103, 104, 105, 106]	TradFi / Volatility	Expiry of stock index futures/options. Creates massive, broad-market “risk-on/risk-off” volatility, which amplifies ETF creation/redemption flows.
Index Rebalance Days	e.g., S&P/Russell rebalances. (e.g., First Friday of Mar, Jun, Sep, Dec) [107]	TradFi / Rebalancing	Large allocators (pensions, funds) rebalance portfolios. This can trigger large, delayed ETF flows (e.g., selling stocks to buy BTC ETF).
U.S. Market/Bank Holidays	(e.g., Thanksgiving, Christmas, New Year’s)	TradFi / Operations	This is a critical, overlooked risk. Banks/TradFi settlement systems are closed. ETF creations/redemptions bunch up. The (T+1) reopening day (e.g., the day after Thanksgiving) sees a bolus of 2-3 days’ worth of settlement, which must happen on-chain. This is a perfect target for an attacker.
Crypto-Native Catalysts	(e.g., Halving Anniversary, major Runes mints/airdrops)	Crypto / Attack Origin	These are the origin of the mempool spike, not the victim. An attacker will time one of these mints to collide with one of the TradFi dates above.

Section V: Synthesis and Actionable OSINT

Drawing together the technical, financial, and adversarial analysis, this section delivers a final conclusion on the nature of the threat. It also provides an actionable, OSINT-based ‘early-warning’ framework for operators to monitor the real-time signals that would precede such a cascade.

A. Conclusion: An Assessment of Network Toxicity

Returning to the initial query, this report distinguishes between two levels of risk.

• A “toxic” flaw would imply a consensus-level protocol failure. This would be a bug that could halt the chain or create invalid bitcoins. Ordinals and Runes do not introduce this.
• Instead, they are demonstrably “hazardous.” They represent a severe application and economic-layer vulnerability. They do not “break Bitcoin” itself. But they create weaponizable externalities that threaten the stability, usability, and financial viability of all other services built on top of the network.

These metaprotocols have successfully weaponized Bitcoin’s fee market. They have created a new, potent vector for financialized denial-of-service (DoS) attacks. The “spam” is no longer a philosophical nuisance. It is a mechanism for imposing a direct financial tax on all other network participants. This particularly affects time-sensitive institutional and financial-layer (e.g., Lightning) transactions.

The impact on ETFs is direct, quantifiable, and explicitly disclosed in SEC filings.²¹ A severe cascade event, colliding with a high-redemption window (e.g., a “bank holiday bunch-up”), will almost certainly force a custodian to activate prospectus clauses. This would mean delaying or halting redemptions. This remains a “black swan” event for the traditional ETF market.

The impact on “Strategy Inc.” is operational and existential. “Strategy Inc.’s” core business model of accumulation ⁶³ is directly taxed by Runes-driven congestion.²³ A cascade forces the company into an impossible choice. It must either pay exorbitant fees (potentially 1.8+ BTC, per Table 3) to execute its core business function, or accept catastrophic counterparty risk by leaving assets on an exchange.

The “cenotaph/indexer” vulnerability is the mechanism that makes these attacks uniquely potent. It creates a user-panic feedback loop ¹⁷ that amplifies mempool congestion far beyond the attacker’s initial “spam” input. This vulnerability is a direct, predictable, and exploitable consequence of layering a complex, stateful, non-consensus protocol (Runes) on top of a fragmented, “reorg-aware” indexer ecosystem.¹⁰

B. The “Paul Revere” Early-Warning Framework (Actionable OSINT)

An “Alpha-to-Omega” cascade can be detected in real-time by monitoring a specific set of Open-Source Intelligence (OSINT) signals. The following matrix provides an actionable framework for an early-warning system.

Table 5: OSINT “Paul Revere” Signal Matrix

Purpose: An actionable matrix for a live risk dashboard, linking specific OSINT data points to phases of the cascade.

Signal / Phase	Data Source / Tool	“Red Flag” Condition to Monitor	Implication / What It Means
Alpha / Beta (Setup / Fee Shock)	mempool.space REST/WebSocket API [108, 109, 110, 111]	1. Steepening Fee Histogram: fastestFee rises >300% above hourFee. 2. Rising Floor: mempoolminfee (minimum relay fee) rises > 5 sat/vB.	1. Panic/RBF storm has begun. Users are aggressively outbidding each other. 2. Mempools are full; nodes are evicting low-fee transactions.
Gamma (Indexer Churn / Policy Fragmentation)	bitcoin-dev / DelvingBitcoin Mailing Lists [112, 113, 114, 115]	Sudden spike in posts with keywords: “package relay,” “TRUC,” “v3,” “OP_RETURN,” “policy,” “standardness”.[116]	The “policy civil war” [25] is flaring up. New client versions (e.g., Knots 27, Core v30 28) are creating “policy islands,” fragmenting the mempool before an attack.
Delta (Reorg Twist / Network Partition)	ForkMonitor.info [91, 92, 117]	A cluster of 1-2 block reorgs or stale blocks within a short time window (e.g., 3+ in 6 hours).	This is the key “Delta” trigger. A normal reorg rate is low. A cluster implies network instability, exactly the kind needed to de-sync indexers and trigger the mass-cenotaph event.
Delta (Routing Attack Accelerant)	BGP Monitoring Services (e.g., Kentik, Cloudflare Radar, bgpstream.com)	BGP prefix hijacks/leaks [81, 82] affecting ASNs known to host major mining pools (e.g., AntPool, F2Pool) or custodians (e.g., Coinbase, Gemini).[118]	This is the “attacker’s hand.” A reorg cluster coincident with a BGP hijack targeting Bitcoin infrastructure 13 is not a coincidence. It is a deliberate, induced partition.
Omega (Institutional Collision)	ETF Sponsor Filings / Press Releases (BlackRock, VanEck, etc.) 21	Any public notice mentioning “delayed settlement,” “operational cutoff,” or “temporary halt to creations/redemptions” citing network conditions.	The “Omega” event has occurred. The cascade has successfully collided with institutional operations, forcing a settlement failure.

Section VI: Mitigation Strategies and Best Practices

While the risks identified are systemic, they are not insurmountable. This section outlines actionable mitigation strategies and operational best practices. These can be employed at the network, application, and institutional layers to defend against these specific attack vectors.

A. Network-Layer Mitigations (Routing Security)

The threat of BGP hijacking and Eclipse attacks is a long-standing area of research.

• Secure Relay Networks: Academic proposals include solutions like SABRE. This is a secure and scalable Bitcoin relay network designed to route blocks through connections that are resilient to BGP routing attacks.⁸⁷
• P2P Layer Hardening: General countermeasures to Eclipse attacks involve improving a node’s connection management. This includes randomizing peer selection and increasing outbound connection slots.¹⁴ These are ongoing areas of development for Bitcoin Core and other clients.

B. Application-Layer Mitigations (Indexer Resilience)

This is the most direct defense against the “Cenotaph/Reorg Collision.”

• “Reorg-Aware” Indexers: The core vulnerability is indexer disagreement during a reorg. Advanced indexer software is being built to be “reorg-aware” from the ground up. For example, Hiro’s “Chainhook” indexer is explicitly designed to detect chain reorgs.¹⁰ It automatically rolls back its internal database to a common ancestor and then re-processes the new canonical chain.¹⁶ This automated consistency check is the primary technical solution to preventing “indexer churn” and the resulting false cenotaphs.

C. Operational-Layer Mitigations (Institutional Best Practices)

For custodians, exchanges, and corporate treasuries, defense is about operational discipline and pre-emptive action.

• Proactive UTXO Management: This is the most critical and effective defense. Institutions cannot be vulnerable to high-fee events if their “must-confirm” transactions are small and efficient. This involves a policy of UTXO Consolidation. Operations teams must proactively and continuously “sweep” small UTXO “dust” into larger, single UTXOs. This must be done during low-fee periods (e.g., weekends).⁹³ As shown in Table 3, the cost of a 1,000-input transaction is catastrophic at high fees; the cost of a 1-input transaction is trivial.
• Robust Custody Protocols: This includes adhering to industry best practices. Examples include deep cold storage ⁶⁴, multi-signature (multisig) wallets (e.g., 4-of-6) ⁵⁵, and formalized, auditable procedures for “cold storage rotation” and key management.⁵⁷
• Risk & Calendar Awareness: Operational teams must avoid scheduling non-essential, large-scale on-chain movements (like cold storage rebalancing) during the high-risk calendar windows identified in Table 4. This is especially true around CME expiry and U.S. bank holidays.
• Fee-Bumping Strategy: Operations must have automated, but measured, fee-bumping policies (RBF/CPFP).¹⁷ These must be able to respond to rising fees without contributing to a “thundering herd” panic retry. This includes having pre-approved, high fee ceilings for mission-critical settlement transactions.

The urgency of these mitigations cannot be overstated. The vulnerabilities described in this report are not theoretical. They are active, exploitable, and their components have been historically proven. Institutional operators who ignore proactive UTXO management and fail to build resilient, reorg-aware infrastructure are exposing themselves and their clients to a direct, quantifiable risk of catastrophic operational failure and settlement delays. Discipline is the only effective defense.

Appendix A: Glossary of Technical Terms

• BGP Hijacking: A network-layer attack where a malicious entity falsely advertises internet routing paths to intercept or “black hole” traffic, potentially partitioning the Bitcoin network.¹³
• Cenotaph: A term in the Runes protocol for a malformed or invalid “runestone” (data payload). Transactions with a cenotaph are burned, destroying the runes—a mechanic that can be triggered by indexer disagreements.⁷
• Eclipse Attack: A targeted network-layer attack where an adversary isolates a single Bitcoin node by monopolizing all its peer-to-peer connections. This allows the attacker to feed it false blockchain data and increase reorg risk.⁶⁵
• Indexer: A separate, second-layer piece of software (e.g., ord, UniSat, Hiro’s Runehook ¹⁰) that scans the Bitcoin blockchain to interpret metaprotocol data (like Runes/Ordinals) and maintain a database of who owns what.⁸
• Mempool (Memory Pool): A “waiting room” on each Bitcoin node holding all valid, unconfirmed transactions that are waiting to be included in a block by a miner.⁶⁵
• OP_RETURN: A Bitcoin script opcode that allows a small amount of arbitrary, prunable (non-UTXO) data to be embedded in a transaction. Runes uses this to store its “runestone” data.³⁹
• P2WPKH (Pay-to-Witness-Public-Key-Hash): A standard Bitcoin SegWit (Segregated Witness) transaction format. It is a modern, efficient address type, and its vbyte structure is used in the report’s cost modeling.³⁰
• RBF (Replace-By-Fee): A Bitcoin node policy that allows a user to “replace” their own unconfirmed transaction in the mempool with a new one that pays a higher fee, often used to speed up “stuck” transactions.¹⁷
• Reorg (Reorganization): A normal, though infrequent, event in Bitcoin where a node discovers a new, “heavier” (longer) blockchain. This forces it to discard its previous chain tip (orphaning blocks) and “roll back” its state to adopt the new canonical chain.⁵⁰
• Satoshis (sats): The smallest divisible unit of a bitcoin. There are 100 million satoshis in one bitcoin. The Ordinals protocol “inscibes” data onto individual satoshis.¹
• UTXO (Unspent Transaction Output): The fundamental building block of Bitcoin. A UTXO is a piece of bitcoin (of a specific value) that has been received but not yet spent. Transactions “consume” existing UTXOs as inputs and create new UTXOs as outputs.³⁴

Works Cited

1. Investopedia, “What Are Bitcoin Ordinals?”, (Date not specified, protocol released Jan 2023). https://www.investopedia.com/what-are-bitcoin-ordinals-7486436
2. Cointime (via Bitget News), “Ordinals may be launched on the Runes mainnet in April next year”, Dec 16, 2023. https://www.bitget.com/news/detail/12560603855645
3. Antony (via EasyCrypto), “Bitcoin fees spiked after halving, which coincides with the launch of Runes protocol…”, Apr 24, 2024. https://hub.easycrypto.com/news/why-bitcoin-fees-spiked-to-us128-after-halving
4. Decipher Media (via Medium), “Runes”, (Date not specified). https://medium.com/decipher-media/runes-b3fa9f6ce20a
5. Tangem Blog, “What are Bitcoin Runes?”, (Date not specified). https://tangem.com/en/blog/post/bitcoin-runes/
6. Cube.Exchange, “What is Chain Reorganization?”, (Date not specified). https://www.cube.exchange/what-is/chain-reorganization
7. Apostolaki, et al. (Princeton University), “Hijacking Bitcoin: Routing Attacks on Cryptocurrencies”, (Date not specified). https://collaborate.princeton.edu/en/publications/hijacking-bitcoin-routing-attacks-on-cryptocurrencies
8. Heilman, et al. (Usenix Security 2015), “Eclipse Attacks on Bitcoin’s Peer-to-Peer Network”, 2015. https://www.usenix.org/system/files/conference/usenixsecurity15/sec15-paper-heilman.pdf
9. Envio Indexer (via Medium), “Indexing Reorgs”, (Date not specified). https://medium.com/@envio_indexer/indexing-reorgs-326f7b6b13ba
10. Tatum, “Bitcoin Replace-By-Fee (RBF) and Stuck Transactions in the Mempool”, (Date not specified). https://docs.tatum.io/docs/bitcoin-replace-by-fee-and-stuck-transactions-in-the-mempool
11. Nasdaq, “Coinbase is Dominating a Key Bitcoin ETF Service”, (Date not specified). https://www.nasdaq.com/articles/coinbase-is-dominating-a-key-bitcoin-etf-service
12. iShares (BlackRock), “Prospectus: iShares Bitcoin Trust”, Dec 31, 2024 (based on URL). https://www.ishares.com/us/literature/prospectus/p-ishares-bitcoin-trust-12-31.pdf
13. NYSE Arca, Inc. (SEC Filing), “Self-Regulatory Organizations; NYSE Arca, Inc… to List and Trade Shares…”, Dec 3, 2024 (based on URL). https://www.sec.gov/Archives/edgar/data/1928561/000121390025088036/ea0257487-01_485apos.htm
14. Strategy Inc. (SEC Filing), “Form 10-K (mstr-20241231)”, 2025. https://www.sec.gov/Archives/edgar/data/1050446/000095017025021814/mstr-20241231.htm
15. Bitcoin Ops, “Transaction size calculator”, (Date not specified). https://bitcoinops.org/en/tools/calc-size/
16. Bankless, “The Bitcoin Knots vs. Core Civil War”, Oct 25, 2025 (based on article text). https://www.bankless.com/read/the-bitcoin-knots-vs-core-civil-war
17. The Block, “Bitcoin Core devs merge controversial OP_RETURN policy change into planned October release”, (Date not specified, release schedule Oct). https://www.theblock.co/post/357594/bitcoin-core-devs-merge-controversial-op_return-policy-change-into-planned-october-release
18. CryptoBriefing, “Dashjr: Runes Are a ‘5-Vector Attack’ on Bitcoin, Not an Exploit”, (Date not specified). https://cryptobriefing.com/dashjr-runes-bitcoin-exploit/
19. Coin98, “Casey Rodarmor: The mastermind behind Bitcoin Ordinals and Runes”, Apr 8, 2024. https://coin98.net/who-is-casey-rodarmor
20. CoinDesk (via YouTube), “From Ordinals to Runes: Meet Bitcoin’s Most Controversial Dev, Casey Rodarmor | Consensus 2024”, 2024. https://www.youtube.com/watch?v=sqfCarDdXPM
21. IQ.Wiki, “Casey Rodarmor”, (Date not specified). https://iq.wiki/wiki/casey-rodarmor
22. Protos, “Ordinals founder Casey Rodarmor to launch Runes at Bitcoin halving”, (Date not specified). https://protos.com/ordinals-founder-casey-rodarmor-to-launch-runes-at-bitcoin-halving/
23. Binance Square, “Runes VS BRC20”, (Date not specified). https://www.binance.com/en/square/post/5421177183297
24. Internet Computer, “Build on BTC: Runes”, (Date not specified). https://internetcomputer.org/docs/build-on-btc/runes
25. PixelPlex, “Bitcoin Runes protocol vs Bitcoin Ordinals protocol”, (Date not specified). https://pixelplex.io/blog/bitcoin-runes/
26. Swan Bitcoin, “What Are Bitcoin Ordinals?”, (Date not specified). https://www.swanbitcoin.com/education/what-are-bitcoin-ordinals/
27. Leather.io, “Ordinals vs Runes”, (Date not specified). https://leather.io/posts/ordinals-vs-runes
28. Crypto.com Research, “Bitcoin Ordinals March 2024”, Mar 2024. https://crypto.com/en/research/bitcoin-ordinals-march-2024
29. CoinMarketCap Academy, “What Is the Runes Protocol?”, (Date not specified). https://coinmarketcap.com/academy/article/what-is-the-runes-protocol
30. MEXC Blog, “What Are Bitcoin Runes: Enabling Memecoins on Bitcoin”, (Date not specified). https://blog.mexc.com/what-are-bitcoin-runes-enabling-memecoins-on-bitcoin-creator-olaseni/
31. Gate.io, “What Are Bitcoin Runes and How Do They Differ From BRC-20 Tokens?”, Oct 27, 2025 (based on article text). https://www.gate.com/learn/articles/what-are-bitcoin-runes-and-how-do-they-differ-from-brc-20-tokens/2782
32. Decrypt, “Bitcoin Runes Launch at the Halving: Here’s Everything You Need to Know”, Mar 2024 (based on article text). https://decrypt.co/221962/bitcoin-runes-launch-at-the-halving-heres-everything-you-need-to-know
33. Decrypt, “Bitcoin Fees Fall After All-Time High Amid Runes Launch”, Apr 23, 2024. https://decrypt.co/227534/bitcoin-fees-fall-after-all-time-high-amid-runes-launch
34. Magic Eden, “Runes Guide”, (Date not specified). https://community.magiceden.io/learn/runes-guide
35. Heilman, et al. (Usenix Security 2015), “Eclipse attacks on bitcoin’s peer-to-peer network”, (Abstract). 2015. https://www.usenix.org/conference/usenixsecurity15/technical-sessions/presentation/heilman
36. Decipher Media (via Medium), “Runes”, (Date not specified). https://medium.com/decipher-media/runes-b3fa9f6ce20a
37. Ordinals.com, “Runes: Specification”, (Date not specified). https://docs.ordinals.com/runes/specification.html
38. Unchained Crypto, “Runes Protocol”, (Date not specified). https://unchainedcrypto.com/runes-protocol/
39. Sovryn, “Bitcoin Runes Tokens”, (Date not specified). https://sovryn.com/all-things-sovryn/bitcoin-runes-tokens
40. Ordinals.com, “Runes”, (Date not specified). https://docs.ordinals.com/runes.html
41. iShares (BlackRock), “Prospectus: iShares Bitcoin Trust”, Dec 31, 2024 (based on URL). https://www.ishares.com/us/literature/prospectus/p-ishares-bitcoin-trust-12-31.pdf
42. Transak, “What are Bitcoin Runes?”, (Date not specified). https://transak.com/blog/what-are-bitcoin-runes
43. mempool.space, “WebSocket API Documentation”, (Date not specified). https://mempool.space/docs/api/websocket
44. Hiro Systems (GitHub), “bitcoin-indexer”, (Date not specified). https://github.com/hirosystems/bitcoin-indexer
45. Hiro Systems (GitHub), “runehook”, (Date not specified). https://github.com/hirosystems/runehook
46. Hiro Systems, “Introducing the Runes API”, (Date not specified). https://www.hiro.so/blog/introducing-the-runes-api
47. Hiro Systems, “Introducing the Runes API”, Jul 23, 2024 (based on article text). https://www.hiro.so/blog/introducing-the-runes-api
48. Learn Me a Bitcoin, “Chain Reorganization”, (Date not specified). https://learnmeabitcoin.com/technical/blockchain/chain-reorganization/
49. Coin Metrics, “Reorg and Fork Tracker Overview”, (Date not specified). https://gitbook-docs.coinmetrics.io/network-data/cm-labs/reorg-and-fork-tracker-overview
50. Reddit (r/Bitcoin), “Questions about bitcoin reorganization process”, 2018 (based on “6y ago”). https://www.reddit.com/r/Bitcoin/comments/g6yv9c/questions_about_bitcoin_reorganization_process/
51. Hiro Systems, “Introducing Chainhook: A Reorg-Aware Transaction Indexer…”, (Date not specified). https://www.hiro.so/blog/introducing-chainhook-a-reorg-aware-transaction-indexer-for-bitcoin-and-stacks
52. Bitcoin Stack Exchange, “During re-org how does bitcoin core validate if the transaction is mined in the…”, (Date not specified). https://bitcoin.stackexchange.com/questions/127512/during-re-org-how-does-bitcoin-core-validate-if-the-transaction-is-mined-in-the
53. QuickNode Blog, “Understanding Blockchain Reorgs…”, (Date not specified). https://blog.quicknode.com/understanding-blockchain-reorgs-why-block-numbers-dont-matter-as-much-as-you-think/
54. The Bitcoin Manual, “What is Ordisrespector?”, Feb 1, 2023 (based on article text). https://thebitcoinmanual.com/articles/what-is-ordisrespector/
55. Stacker.news (via Medium), “Bitcoin Filters Work By Default”, (Date not specified). https://medium.com/@Fiach_dubh/bitcoin-filters-work-by-default-f3ae50d304a6