DoS via Inscription Junk Data & Decompression Bombs

introduction

DENIAL-OF-SERVICE VIA INSCRIPTION JUNK DATA AND DECOMPRESSION BOMBS

Attack Class: Indexer Resource Exhaustion

A class of attacks where maliciously crafted inscription data is designed to crash or overwhelm Ordinals and Runes indexers, causing widespread service denial.

The reliance of Bitcoin Ordinals and Runes on off-chain indexers creates a distinct attack surface: resource exhaustion at the parsing layer. Unlike Bitcoin Core, which validates consensus rules, indexers must interpret arbitrary witness data to track inscription ownership and Runes balances. Malicious actors exploit this by inscribing payloads specifically engineered to consume excessive CPU, memory, or disk I/O during indexing. Common vectors include recursive inscription loops that force an indexer into unbounded processing, deeply nested JSON structures, and decompression bombs—small compressed payloads that expand to gigabytes of junk data, crashing the indexer process.

The operational impact is immediate and systemic. A successful attack can take a primary indexer offline, causing cascading failures across all dependent services: marketplaces display incorrect listings, wallets show missing assets, and Runes balances become unreliable. The ord indexer, maintained by the protocol's creator, has historically been the single point of failure, though alternative implementations like ordhook and alkanes have introduced some diversity. Countermeasures implemented include configurable limits on inscription depth, payload size caps, and memory-bounded decompression routines. However, these are off-chain policy decisions, not consensus rules, meaning each indexer operator must independently configure and maintain their defenses.

Indexer operators and protocol developers should treat this as an ongoing threat requiring continuous hardening. A stress-test review of parsing and validation logic against these known attack vectors is essential. Teams running custom indexers or relying on third-party APIs must verify that their provider has implemented robust resource limits and has a tested failover strategy. Chainscore Labs can conduct a targeted review of your indexer's input validation, recursive parsing safeguards, and decompression handling to ensure resilience against resource exhaustion attacks.

DENIAL-OF-SERVICE VIA INSCRIPTION JUNK DATA AND DECOMPRESSION BOMBS

Incident Snapshot

A structured breakdown of the attack vectors, affected components, and required operational responses for the class of DoS attacks targeting Ordinals and Runes indexers through maliciously crafted inscription data.

Attack Vector	Failure Mode	Affected Systems	Operational Impact	Mitigation Action
Recursive Inscription Loops	Indexer enters infinite loop attempting to resolve self-referencing or deeply nested inscription pointers, exhausting CPU and memory.	Ord indexer, custom indexer implementations, marketplace backends	Indexer process crash, API unavailability, stalled transaction ingestion, delayed balance updates.	Implement recursion depth limits and cycle detection in pointer resolution logic. Review against ord reference client patches.
Decompression Bombs (Zip Bombs)	Indexer decompresses a small inscribed payload that expands to gigabytes of data, exhausting disk space or memory.	Ord indexer, any service performing automated decompression of inscription content for rendering or metadata extraction.	Node disk exhaustion, out-of-memory kills, cascading failure of co-located services, potential data corruption.	Enforce strict maximum decompressed size limits before processing. Sandbox decompression in ephemeral environments with hard resource quotas.
Excessively Large Data Payloads	Indexer attempts to parse and store a single inscription containing a multi-gigabyte valid data payload, overwhelming I/O and storage.	Ord indexer, block explorers, wallet backends fetching full inscription content.	API timeouts, degraded user experience, increased infrastructure costs from storing junk data, potential denial-of-service for legitimate requests.	Enforce and configure a maximum inscription content size limit. Reject or truncate oversized payloads at the ingestion boundary. Verify current default limits in canonical indexer releases.
Parser Vulnerability Exploitation	Malformed data crafted to trigger a buffer overflow, panic, or unhandled exception in the indexer's binary or content-type-specific parser.	Ord indexer, any custom tooling using ord libraries for inscription parsing.	Indexer crash, potential for remote code execution depending on the vulnerability class, requiring emergency patch deployment.	Run indexer software with minimal privileges. Implement fuzz-testing against the inscription parsing stack. Monitor for and apply security patches from the ord reference implementation immediately.
Mempool Flooding with Junk Inscriptions	Attacker broadcasts a high volume of transactions containing junk inscriptions, saturating the Bitcoin mempool and the indexer's ingestion pipeline.	Bitcoin node mempool, Ord indexer ingestion pipeline, marketplace order-matching engines.	Increased transaction fees network-wide, indexer ingestion lag, delayed order matching, potential for double-spend or order-matching race conditions.	Implement rate limiting on indexer ingestion. Scale indexer infrastructure horizontally. Marketplace operators should review their transaction finality and order-matching architecture against mempool congestion scenarios.

technical-context

INDEXER RESOURCE EXHAUSTION

Attack Vectors and Technical Mechanism

A technical breakdown of how malicious inscription payloads are constructed to crash or overwhelm Bitcoin Ordinals and Runes indexers.

The Denial-of-Service (DoS) attack class against Bitcoin Ordinals and Runes infrastructure targets the off-chain indexers that parse witness data to construct a canonical state of digital artifacts. Unlike a consensus-layer attack on Bitcoin itself, these vectors exploit the resource constraints of the ord indexer and similar implementations. The core mechanism involves inscribing computationally pathological data—such as recursive inscription chains, deeply nested JSON, or decompression bombs—that force an indexer to consume exponential time, memory, or disk I/O during the parsing and validation phase, leading to a crash or an indefinite stall in block processing.

A common technical pattern is the 'recursive inscription loop,' where an inscription references the content of another inscription that, in turn, references the first, creating an infinite dereferencing cycle. Another potent vector is the 'zip bomb,' where a relatively small inscribed payload decompresses to gigabytes or terabytes of junk data, exhausting the indexer's storage and memory allocation. Excessively large data payloads that skirt default size limits by exploiting edge cases in content-type parsing also fall into this category. The operational impact is immediate: indexer unavailability causes a complete loss of asset visibility across dependent marketplaces, wallets, and explorers, effectively freezing all inscription and Runes trading activity until the operator manually intervenes and deploys a patch.

Countermeasures have evolved to include strict recursion depth limits, maximum decompressed output size checks applied before decompression, and hard byte-size caps on individual inscription content. However, the attack surface remains tied to the complexity of the parsing logic. Indexer operators and protocol developers should not rely solely on default limits; a stress-test review of their parsing and validation logic against these specific payload patterns is essential to ensure operational resilience. A failure to handle a new edge case can lead to a state divergence event where different indexers, applying different patches, disagree on the canonical chain, compounding the initial DoS with a long-term asset integrity problem.

IMPACT ASSESSMENT

Affected Systems and Actors

Indexer Operators

Indexer operators are the primary target and most severely affected party. Malicious inscriptions containing recursive loops, deeply nested JSON, or decompression bombs (e.g., zip bombs with extreme compression ratios) are designed to exhaust CPU, memory, or disk resources during parsing.

Impact:

Service degradation or complete outage as indexers stall on a single malicious transaction.
Potential for state corruption if a crash occurs mid-write.
Resource exhaustion can cascade to dependent services like APIs and block explorers.

Action Items:

Implement strict resource limits (memory, CPU time, recursion depth) in parsing logic.
Add decompression bomb detection by checking the ratio of compressed to decompressed size before processing.
Deploy a staging indexer to validate new transaction patterns before production ingestion.
Chainscore Labs can conduct a stress-test review of your parsing and validation logic against known attack vectors.

implementation-impact

DEFENSE-IN-DEPTH STRATEGIES

Countermeasures and Mitigations

A layered approach to defending indexers and parsing infrastructure against inscription-based denial-of-service attacks, from input validation to architectural isolation.

Strict Input Validation and Size Limits

Indexers must enforce hard limits on inscription data size, recursion depth, and decompressed payload size before processing. Reject transactions where the witness data exceeds a configured byte limit or where nested inscription references exceed a safe recursion depth. Implement streaming parsers that abort early when decompressed data crosses a threshold, preventing zip bombs from exhausting memory. Operators should review their current limits against known attack payloads and ensure limits are configurable to adapt to new attack patterns without requiring a full release.

Resource-Constrained Sandboxing

Run inscription parsing and decompression in isolated, resource-constrained environments with hard CPU timeouts, memory caps, and no network access. Container-based sandboxing or seccomp-bpf filters can prevent a single malicious inscription from crashing the entire indexer process. If a parser exceeds its resource budget, the inscription should be marked as unprocessable and skipped without affecting the indexing of other transactions. Indexer operators should audit their current process architecture to ensure parsing failures are contained and do not cascade into full service outages.

Recursive Inscription Loop Detection

Implement cycle detection in the inscription reference graph before attempting to resolve recursive inscriptions. Indexers should maintain a visited set during resolution and reject any inscription chain that references an ancestor, preventing infinite loops that exhaust stack space or CPU. The detection logic must be integrated into the core indexing pipeline, not as a post-processing step, to stop resource exhaustion before it begins. Teams building custom indexers should test their resolution logic against known recursive inscription payloads from the mainnet to verify correct rejection behavior.

Rate Limiting and Priority Queuing

Deploy rate limiting at the indexer API and mempool ingestion layers to prevent attackers from flooding the system with junk inscriptions. Implement priority queuing that processes transactions with standard inscription envelopes before attempting to parse non-standard or suspicious payloads. This ensures that legitimate indexing work proceeds even under active attack. Operators should configure alerts for sudden spikes in rejected or deferred inscriptions, which may indicate an ongoing DoS attempt requiring manual intervention or rule updates.

Indexer Implementation Diversity

Relying on a single indexer implementation creates a systemic risk where a parsing vulnerability can take down the entire ecosystem's view of inscription state. Teams should run multiple independent indexer implementations in parallel and cross-reference their outputs. Divergence alerts should trigger automatic failover and manual investigation. Marketplace operators and wallets that depend on indexer APIs should integrate with at least two independent providers to maintain service availability when one implementation is targeted or experiences a bug triggered by a specific payload.

Chainscore Labs Indexer Stress-Test Review

Chainscore Labs can conduct a targeted stress-test review of your indexer's parsing and validation logic against the full catalog of known inscription-based DoS vectors, including recursive loops, zip bombs, and oversized payloads. The engagement delivers a prioritized remediation plan covering input validation gaps, sandboxing weaknesses, and architectural single points of failure. Teams operating custom indexers or integrating with third-party APIs should schedule a review to ensure their infrastructure can withstand the next wave of attack payloads.

DENIAL-OF-SERVICE VIA INSCRIPTION JUNK DATA AND DECOMPRESSION BOMBS

Risk Assessment Matrix

Evaluates the failure modes, affected actors, and required actions for the class of attacks where malicious inscription data is designed to crash or overwhelm indexers, including recursive loops, zip bombs, and excessive payloads.

Risk	Failure mode	Severity	Affected actors	Mitigation and action
Recursive inscription loops	Indexer follows a chain of self-referencing inscriptions, consuming infinite CPU and memory until process crash	Critical	Indexer operators, marketplace backends, wallet providers	Implement recursion depth limits and cycle detection in parsing logic. Verify against canonical indexer patches.
Decompression bomb (zip bomb)	A small inscribed payload expands to gigabytes of data, exhausting indexer memory and disk	Critical	Indexer operators, data teams, API providers	Enforce maximum decompressed size limits before expansion. Conduct a stress-test review of decompression routines.
Excessively large data payload	A single inscription near or at the maximum size limit causes timeouts and resource exhaustion during parsing	High	Indexer operators, wallet backends, explorers	Set and enforce strict size limits on inscription content. Implement streaming parsers with timeouts.
Repeated junk inscriptions (flood attack)	A high volume of valid but useless inscriptions saturates indexer ingestion pipelines, degrading service	Medium	Indexer operators, marketplace order books	Implement rate limiting per block or transaction pattern. Scale ingestion horizontally and monitor for anomalous volume spikes.
Parser vulnerability exploitation	Crafted binary payloads trigger buffer overflows or logic errors in custom parsers for inscription content types	High	Indexer developers, wallet developers	Sandbox content parsing. Fuzz-test all parsers with malformed inputs. Use memory-safe languages for parsing untrusted data.
Indexer state corruption	A malicious payload causes the indexer to write inconsistent state to its database, requiring a full re-index	High	Indexer operators, all downstream consumers	Validate state integrity after each block. Implement automatic rollback to last known good state. Verify recovery procedures.
API denial-of-service via expensive queries	Attackers request complex queries against indexer APIs that traverse junk data, exhausting database resources	Medium	API providers, marketplace frontends	Implement query complexity limits, pagination, and caching. Monitor for abusive query patterns.
Cross-implementation divergence	Different indexer implementations handle the same malicious payload differently, causing a chain split in asset views	High	Wallet teams, exchanges, bridge operators	Standardize error handling and rejection criteria across implementations. Conduct cross-implementation conformance testing.

DEFENSE AGAINST JUNK DATA AND DECOMPRESSION BOMBS

Indexer Hardening Checklist

A practical checklist for indexer operators and protocol developers to validate their parsing and validation logic against denial-of-service vectors that exploit malicious inscription data. This list focuses on the specific attack classes of recursive inscription loops, zip bombs, and excessively large data payloads.

What to check: Ensure your indexer enforces a strict maximum byte size on raw witness data before any decompression or parsing logic is applied.

Why it matters: Decompression bombs (zip bombs) rely on a small compressed payload expanding to gigabytes of data in memory. Without a pre-decompression size limit, an attacker can exhaust RAM and crash the indexer with a single transaction.

Signal of readiness: The indexer rejects any witness envelope exceeding a configured maximum raw byte size (e.g., 400KB for an individual inscription) and logs the rejection as a security event without attempting to decompress the payload.

resource-links

CANONICAL SPECS AND SECURITY GUIDANCE

Source Resources and References

Use these resources to assess denial-of-service exposure from inscription junk data, recursive content, oversized payloads, and decompression bombs. They separate Bitcoin consensus behavior from the additional parsing and rendering risks introduced by Ordinals indexers and applications.

Ordinals Inscription Specification

Review the Ordinals handbook before changing envelope parsing, content extraction, or validation behavior. Bitcoin nodes validate transactions and witness data under Bitcoin consensus rules; they do not validate inscription media as safe application content. Indexers must therefore treat content types, bodies, unknown fields, malformed envelopes, and large payloads as untrusted input. Derive explicit limits for bytes scanned per transaction, inscriptions processed per block, metadata retained, and work performed before rejection. Test those limits against confirmed chain data rather than assuming mempool policy will prevent hostile payloads from being mined.

EXPLORE

Recursive Inscription Semantics

Recursive inscriptions can cause an indexer, gateway, or renderer to retrieve and compose content from other inscriptions. Implementations should cap recursion depth, total referenced objects, cumulative fetched bytes, execution time, and repeated visits to the same inscription identifier. Maintain a per-request visited set to terminate cycles, and resolve content through a bounded worker pool rather than recursively on the request thread. Cache only successfully validated results, preserve negative-cache entries for known cycles, and ensure one adversarial dependency graph cannot exhaust shared database, network, or rendering capacity.

EXPLORE

Ord Indexer Source and Issue History

Use the reference ord implementation to compare parsing rules, release changes, and operational assumptions with custom indexers. Review commits and issues affecting envelope recognition, recursion, content serving, database writes, reindexing, and malformed-input handling before deploying an upgrade. Pin reviewed revisions, reproduce fixes in a staging index built from adversarial fixtures, and monitor resident memory, CPU time, queue depth, database growth, and crash loops during replay. A difference from ord is not automatically incorrect, but it should be documented because marketplaces and wallets may otherwise derive conflicting asset state.

EXPLORE

CWE-409: Data Amplification

MITRE CWE-409 describes the failure mode behind decompression bombs: a small compressed input triggers disproportionate memory, storage, or CPU consumption. Apply this model whenever inscription content is decoded, transcoded, unpacked, rasterized, or passed to media libraries. Enforce limits on expanded bytes and compression ratios while streaming, not after full allocation. Disable nested archive expansion unless required, isolate decoders with memory and CPU quotas, and terminate work when budgets are exceeded. Record the inscription identifier, decoder, declared media type, observed type, expansion ratio, and rejection reason for incident correlation.

EXPLORE

OWASP File-Handling Controls

Treat inscription bodies as hostile uploaded files even though they originate from Bitcoin witness data. OWASP’s file-upload guidance provides applicable controls: verify format signatures instead of trusting declared content types, restrict supported formats, randomize temporary paths, scan or sandbox risky content, and store untrusted files away from executable or web-serving contexts. For immutable on-chain data, rejection means refusing to decode or render the object—not rewriting it. Serve raw bytes with safe response headers where necessary, prevent browser content sniffing, and keep rendering services isolated from indexer state and signing infrastructure.

EXPLORE

Bitcoin Transaction and Witness Boundaries

Use Bitcoin’s transaction documentation to define the boundary between consensus-valid transaction data and application-level inscription interpretation. An inscription can be valid Bitcoin data while remaining unsafe for an indexer, API, thumbnail generator, or browser renderer. Architecture reviews should map each transition from block ingestion through witness parsing, content persistence, API delivery, decompression, and rendering. Apply independent quotas and failure isolation at every transition. Do not let malformed media handling roll back canonical chain indexing; quarantine the content record, retain enough metadata for deterministic replay, and continue processing unrelated transactions where state-consistency rules permit.

EXPLORE

Chains We Build On

Looking to build on a specific blockchain?

We build smart contracts, DeFi applications, wallets, tokenization platforms, and blockchain infrastructure across the major ecosystems teams choose today. That includes Ethereum, Arbitrum, Optimism, Polygon, Avalanche, Solana, Sui, Aptos, Hedera, Stellar, and NEAR, with support for additional EVM and non-EVM networks based on your product requirements.

Learn More

EVM ecosystems

Ethereum
Arbitrum
Optimism
Polygon
Avalanche
Cronos

Non-EVM ecosystems

Solana
Sui
Aptos
Hedera
Stellar
NEAR

Additional ecosystems

Polkadot
Cosmos
TON
Cardano
Algorand
Tempo

Also available for Base, appchains, custom EVM networks, and cross-chain product architecture.

DOS ATTACK VECTORS AND INDEXER HARDENING

Frequently Asked Questions

Common questions about the class of denial-of-service attacks that target Ordinals and Runes indexers through maliciously crafted inscription data, including decompression bombs, recursive loops, and oversized payloads. These answers are designed for indexer operators, protocol developers, and infrastructure teams hardening their parsing and validation pipelines.

A decompression bomb (or 'zip bomb') is a maliciously crafted compressed file that is small when stored but expands to an enormous size when processed. In the context of Ordinals, an attacker inscribes such a file within a valid inscription envelope. When an indexer attempts to parse and decompress the inscription content—for example, to render a preview or extract metadata—it can exhaust memory, disk space, or CPU, causing the indexer process to crash or the host to become unresponsive. The attack exploits the assumption that inscribed data is safe to process. Mitigation requires indexers to enforce strict limits on decompressed output size, total decompression time, and recursion depth, independent of the on-chain size of the inscription witness.

Trusted by Industry Leaders

Delivering blockchain solutions for 5+ years.

We have partnered with 50+ leading DeFi protocols, NFT ecosystems, and fintech innovators to build secure, scalable, and capital-efficient blockchain products.

Selected Partners & Clients

“I've been working with Chainscore Labs for last 3+ years, they've consistently delivered with strong ownership across multiple projects. The team is reliable and detail-oriented.”

Lee Erswell

CEO, Telos Foundation

how to get started

How to get started?

If you're looking for blockchain integration, ChainScore Labs has 5+ years of experience helping teams build and integrate exchanges, wallets, smart contracts, tokenization solutions, and protocol-connected products, we can help you choose the right path, integrate securely, and get to production faster. Our team consists of experienced blockchain developers and architects who can help you with your blockchain integration needs.

Exploration & Strategy

Define your product goals and choose the right blockchain architecture for your use case.

Architecture & Design

Design the smart contracts, tokenomics, and security parameters of your system.

Development & Integration

Build and integrate with wallets, oracles, and front-end dApps for a seamless experience.

Security & Launch

Comprehensive audits followed by a risk-managed mainnet deployment to protect your users.

Learn More

Explore More Solutions

Discover our
blockchain development services.

We build production-grade blockchain solutions for top-tier projects across DeFi and Web3.

Book a Call

DeFi Protocol Development

End-to-end development of custom DeFi protocols including core smart contracts and system architecture.

DEX & Exchange Development

Building high-performance decentralized exchanges with optimized liquidity and advanced trading logic.

Lending & Borrowing Platforms

Scalable credit markets and money protocols built for production-grade liquidity and security.

Denial-of-Service via Inscription Junk Data and Decompression Bombs

Attack Class: Indexer Resource Exhaustion

Incident Snapshot

Attack Vectors and Technical Mechanism

Affected Systems and Actors

Indexer Operators