The Parent-Child Inscription Provenance Standard defines a method for establishing a verifiable, on-chain lineage between individual inscriptions on Bitcoin. By including a parent field within a new inscription's envelope that references the genesis transaction ID of a prior inscription, a cryptographically verifiable parent-child relationship is created. This standard is foundational for the Ordinals ecosystem, enabling the creation of coherent, provably linked collections without relying on off-chain metadata or centralized servers to define membership.
Protocols
Parent-Child Inscription Provenance Standard
Standard for establishing verifiable on-chain lineage between inscriptions using the parent field. Affects wallets, explorers, and marketplaces that display collection provenance.
introduction
ON-CHAIN COLLECTION LINEAGE
What is the Parent-Child Inscription Provenance Standard?
A standard for establishing verifiable on-chain lineage between inscriptions using the parent field, critical for authenticating collection provenance.
Operationally, this standard shifts the burden of collection verification from centralized indexers and marketplaces to the Bitcoin blockchain itself. A wallet, explorer, or marketplace can independently verify an inscription's provenance by tracing its parent field back to a known root inscription. This directly combats provenance spoofing, where a malicious actor creates an inscription that mimics the metadata of a valuable collection but lacks the on-chain lineage to prove it. For builders, implementing this verification logic is critical; a failure to correctly parse and validate the parent chain can lead to fraudulent assets being displayed as authentic, causing reputational and financial damage.
The standard introduces specific integration requirements for indexer operators and wallet developers. Indexers must correctly parse the parent field and construct a provenance graph, while wallets must manage UTXOs carefully to avoid accidentally spending or burning an inscription that serves as a parent to others. Chainscore Labs can audit provenance-chain verification logic in wallets and marketplaces to ensure accurate historical tracking, and review indexer implementations to confirm they correctly construct and expose the provenance graph, preventing state divergence that could be exploited.
PARENT-CHILD PROVENANCE
Quick Facts
Operational impact and verification requirements for the parent-child inscription provenance standard across the ecosystem.
| Area | What changes | Who is affected | Action |
|---|---|---|---|
Provenance Model | Inscriptions can reference a parent inscription via the parent field, creating an on-chain lineage chain. | Wallets, explorers, marketplaces | Verify that provenance-chain resolution logic matches the canonical ord indexer behavior. |
Collection Integrity | A single parent inscription can define a collection root; all valid children must point to it. | Collection creators, marketplace curators | Audit collection verification to ensure only inscriptions with the correct parent are recognized as members. |
Spoofing Risk | An attacker could create an inscription that falsely claims a parent to misrepresent provenance. | Marketplaces, wallet display layers | Implement server-side and client-side checks that validate the parent field against on-chain data. |
Indexer Dependency | Provenance chains are resolved off-chain by indexers; divergent implementations cause state splits. | Indexer operators, data teams | Monitor multiple indexer APIs for consistency in parent-child relationship resolution. |
Wallet UX | Wallets must display provenance lineage and warn users when an inscription's claimed parent cannot be verified. | Wallet developers | Integrate provenance verification into asset detail views and transfer confirmation screens. |
Marketplace Listings | Listing and bidding logic must incorporate provenance checks to prevent sale of misrepresented assets. | Marketplace backend engineers | Add parent-field validation to order-matching and listing-creation pipelines. |
Bridge Assumptions | Bridges that move inscriptions to L2s must preserve and re-verify the parent-child relationship. | Bridge operators, L2 integration teams | Conduct a trust-model assessment to ensure provenance integrity is maintained across layers. |
Standard Evolution | The parent field usage is governed by the ord reference implementation and community OIP process. | Protocol architects, infrastructure leads | Track OIPs and ord releases for changes to parent-field semantics or validation rules. |
technical-context
ON-CHAIN PROVENANCE LINKING
Technical Mechanism: The Parent Field
The parent field establishes a cryptographically verifiable on-chain lineage between inscriptions, enabling trustless collection provenance without relying on off-chain metadata.
The parent field is a metadata attribute embedded within an inscription's envelope that references the transaction ID (txid) of a prior inscription, creating a directed acyclic graph of provenance on the Bitcoin blockchain. When an indexer encounters an inscription containing a parent reference, it interprets the new inscription as a child of the referenced parent, establishing a verifiable lineage that does not depend on any off-chain database or centralized registry. This mechanism is fundamental to the Parent-Child Inscription Provenance Standard and is used by Ordinals collections to prove that a set of inscriptions belongs to a single logical collection authored by the same creator, without requiring an on-chain registry contract as seen in Ethereum-based NFTs.
The parent field is validated by indexers such as ord by confirming that the referenced parent inscription exists and is not itself a child of another inscription, enforcing a strict two-level hierarchy in the reference implementation. This constraint prevents deep, recursive provenance chains that could complicate balance tracking and state reconciliation. For wallet developers, the parent field introduces a dependency: UTXOs containing child inscriptions must be managed carefully to avoid accidental spending that would orphan the provenance link. Marketplace and explorer teams must query the parent field to correctly group inscriptions into collections and display provenance graphs, and discrepancies between indexer implementations in handling malformed or missing parent references can lead to divergent views of collection membership.
The operational risk for builders lies in the off-chain interpretation layer. A child inscription's provenance is only as reliable as the indexer that validates the parent reference; if an indexer fails to verify the parent's existence or applies different validity rules, users may see conflicting collection assignments across wallets and marketplaces. Chainscore Labs can audit provenance-chain verification logic in indexer plugins, wallet backends, and marketplace order validators to ensure consistent handling of parent references, detection of circular or broken provenance links, and resilience against spoofing attacks where a malicious actor inscribes a false parent reference to misrepresent collection affiliation.
PROVENANCE IMPLEMENTATION IMPACT
Affected Actors
Wallet Integration Requirements
Wallet teams must implement parent-child relationship parsing to correctly display collection provenance. This requires reading the parent inscription ID from the envelope and traversing the chain of custody to the root.
Critical actions:
- Update UTXO selection logic to prevent accidental spending of parent inscriptions when constructing child transactions.
- Implement recursive validation to verify the complete provenance chain, not just the immediate parent.
- Add UI indicators for verified lineage vs. unverified claims to prevent provenance spoofing.
Failure modes: Wallets that ignore the parent field risk displaying forged collection membership, enabling phishing attacks where fake inscriptions appear within legitimate collections. Incorrect UTXO management can break provenance chains by spending parent inscriptions as fees.
implementation-impact
PROVENANCE VERIFICATION
Implementation Impact and Integration Requirements
The parent-child standard introduces a new dependency chain for asset validity. Wallets, explorers, and marketplaces must implement provenance verification to prevent spoofed collections and ensure accurate historical lineage.
01
Provenance Chain Traversal Logic
Implementations must recursively resolve the parent field to construct a complete lineage tree for any given inscription. A naive implementation that only checks one level deep is vulnerable to provenance spoofing. Indexers and wallets should build a directed acyclic graph (DAG) in their data models, with cycle-detection logic to prevent infinite loops from malformed or malicious inscription chains. The canonical root of a collection is the inscription with a null parent field. Teams must define a maximum traversal depth to prevent denial-of-service attacks via excessively deep chains.
02
Collection Root-of-Trust Verification
Marketplaces and explorers must not rely solely on the parent-child chain for authenticity. A malicious actor can fork a legitimate collection by creating a new inscription that points to a genuine parent, then minting a counterfeit collection beneath it. Implementations must cross-reference the purported root inscription against a known set of creator addresses or a community-curated registry. Chainscore can audit this verification logic to ensure that UI-level 'collection' badges are not assigned to unauthorized forks, preventing user confusion and fraudulent listings.
03
Indexer State Reconciliation
Different indexer implementations may resolve parent-child relationships at different speeds or with different conflict-resolution rules, especially during chain re-organizations. Wallets and marketplaces that query multiple indexers must implement a reconciliation layer to detect state divergence. A balance displayed by one indexer may not include a recently invalidated child inscription that another indexer has already pruned. Teams should monitor for 'orphaned' inscriptions where the parent transaction has been invalidated, and surface these clearly to users rather than silently hiding the asset.
04
Wallet UTXO Management for Provenance
Standard wallet UTXO selection algorithms are unaware of inscription provenance and may inadvertently spend a parent inscription as a transaction input, breaking the on-chain lineage for all its children. Wallet developers must implement a 'provenance lock' mechanism that prevents parent inscriptions from being used as ordinary inputs in fee-paying transactions. This requires integration with the wallet's coin-selection engine to treat parent-bearing UTXOs as frozen unless explicitly unlocked by the user for a provenance-aware transfer.
05
Marketplace Listing and Metadata Integrity
A listing for a child inscription must dynamically present the full provenance chain to the buyer, not just the immediate parent. Marketplaces should fetch and display the root inscription's metadata as the collection-level identifier. If the parent chain is broken or points to a known fraudulent root, the listing UI must display a prominent warning. Chainscore can review the order-book and listing-creation logic to ensure that provenance checks are performed server-side at listing time and client-side at purchase time, preventing race conditions.
06
Provenance Audit and Monitoring Service
Teams operating high-value collections or marketplaces should implement continuous provenance monitoring. This service would detect on-chain events that break lineage, such as a parent inscription being transferred to a burn address or spent as a fee. An alerting system should notify collection owners and integrated platforms so they can update their off-chain metadata to reflect the broken chain. Chainscore can design and deploy this monitoring infrastructure to provide real-time integrity assurance for provenance-dependent applications.
PARENT-CHILD LINEAGE INTEGRITY
Risk Matrix: Provenance Verification
Evaluates the operational risks and verification requirements for systems that display, trade, or index collections based on the parent-child inscription provenance standard.
| Area | Failure Mode | Who is affected | Severity | Action |
|---|---|---|---|---|
Parent Field Parsing | Indexer or wallet fails to parse the parent field from the inscription envelope, breaking the lineage chain. | Wallets, Explorers, Marketplaces | High | Audit envelope parsing logic against the canonical ord reference implementation to ensure the parent field is extracted correctly. |
Provenance Spoofing | A malicious actor creates an inscription with a forged parent pointer to a high-value collection, gaining false attribution. | Marketplaces, Collectors | Critical | Implement server-side verification that the parent inscription exists and was created before the child. Chainscore can audit this verification logic. |
Reorg-Induced Orphan | A blockchain reorganization invalidates the parent inscription, orphaning all children and breaking the displayed collection. | Indexer Operators, Marketplaces | High | Monitor for chain reorgs and implement a confirmation-depth policy before finalizing parent-child relationships in application state. |
Cross-Indexer Inconsistency | Different indexer implementations disagree on the validity or order of a parent-child relationship, causing state divergence. | Marketplaces, Wallets, Portfolio Trackers | Medium | Query multiple indexers to detect discrepancies. Adopt an abstraction layer to switch providers if one indexer's state is deemed incorrect. |
Circular Dependency | A recursive or circular parent reference chain causes infinite loops in rendering or balance calculation logic. | Explorers, Wallets | Medium | Implement cycle detection in the provenance graph traversal algorithm and set a maximum depth limit for rendering a lineage. |
Cursed Parent Attribution | A child inscription references a cursed parent, leading to inconsistent display or valuation across platforms. | Marketplaces, Collectors | Medium | Define a clear policy for handling children of cursed inscriptions. Verify the policy against major marketplaces to avoid user confusion. |
Delegation Interaction | A delegated inscription is used as a parent, creating ambiguity about the true authority over the child's provenance. | Collection Managers, Marketplaces | Low | Document the interaction between the delegate and parent fields. Validate that order-matching logic correctly identifies the authorized party. |
PROVENANCE INTEGRITY
Verification Logic Audit Checklist
A practical checklist for auditing the verification logic that establishes on-chain lineage between parent and child inscriptions. Use this to ensure your wallet, explorer, or marketplace correctly validates provenance chains and is not susceptible to spoofing or indexer divergence.
What to check: Verify that the parser correctly extracts the parent inscription ID from the child inscription's envelope and resolves it to a canonical format (e.g., {txid}i{index}). The logic must handle edge cases like missing fields, malformed IDs, and multiple parent references.
Why it matters: Incorrect parsing is the most common source of provenance failure. A malformed ID that is silently accepted or resolved to an incorrect inscription creates a false lineage that is indistinguishable from a genuine one to downstream consumers.
Readiness signal: The parser rejects inscriptions with non-canonical parent IDs and produces the same resolved parent ID as the ord reference indexer for a test suite of valid and invalid envelopes.
resource-links
CANONICAL SPECS AND VERIFICATION TOOLS
Source Resources
Use these resources to confirm parent-child inscription rules, inspect reference behavior, and independently verify provenance claims against Bitcoin transaction data.
06
Provenance Verification Test Plan
Build conformance tests from canonical examples and adversarial variants before enabling collection badges or inherited metadata. Cover nonexistent parent identifiers, a valid parent field without the required parent input, malformed identifiers, duplicate parent declarations, multi-parent cases, reinscriptions, reorg recovery, and indexer rollback. Require the listing pipeline to fail closed or mark lineage as unverified when providers disagree. Chainscore Labs can review provenance-graph construction, transaction-level verification, caching, and reconciliation logic against pinned ord behavior.
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.
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.
PROVENANCE VERIFICATION FAQ
Frequently Asked Questions
Common operational and integration questions for teams implementing parent-child inscription provenance verification. Covers indexer behavior, edge cases, and practical guidance for wallets, marketplaces, and explorers.
The indexer reads the parent field within the inscription envelope of the child inscription. This field contains the inscription ID (a txid and output index) of the parent. The indexer then traverses this reference to build a provenance chain. What to check: Verify that your indexer implementation correctly parses the parent field from the envelope and does not rely on off-chain metadata or transaction ordering. Why it matters: Incorrect parsing can break provenance chains, causing collections to appear fragmented or allowing spoofed lineage. Signal of readiness: A test suite that includes inscriptions with valid, invalid, and self-referential parent IDs, confirming the indexer builds the correct tree structure.
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.”
L
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.
01
Exploration & Strategy
Define your product goals and choose the right blockchain architecture for your use case.
02
Architecture & Design
Design the smart contracts, tokenomics, and security parameters of your system.
03
Development & Integration
Build and integrate with wallets, oracles, and front-end dApps for a seamless experience.
04
Security & Launch
Comprehensive audits followed by a risk-managed mainnet deployment to protect your users.
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
Start a build
Need a blockchain engineering team?
Send the project context and we will respond with next steps, scope questions, and a practical path to delivery.