The introduction of Ordinals and Runes has transformed Bitcoin UTXOs from fungible units of value into carriers of non-fungible and semi-fungible state. This shift breaks a fundamental assumption embedded in nearly all institutional multisig and MPC custody systems: that any UTXO of a given value is interchangeable with any other. When a collaborative custody workflow selects an inscribed satoshi or a Runes-bearing UTXO as a fee input, consolidates it during a routine sweep, or fails to preserve its location during a key reshare, the asset is permanently destroyed. The loss is not a blockchain-level exploit but a predictable failure of wallet logic that was never designed to recognize inscription envelopes or Runes state transitions.
Protocols
Multisig and Collaborative Custody Mishandling of Inscriptions
Documents specific failure modes when using multisig or MPC wallets to hold Ordinals or Runes, including signing devices not recognizing inscription envelopes, incorrect PSBT construction in collaborative custody setups, and operational risks during recovery.
introduction
CUSTODIAL THREAT MODEL
Introduction
Why multisig and MPC wallets routinely destroy or lose access to Ordinals and Runes, and the operational changes required to prevent it.
The failure modes are systemic and span the entire custody lifecycle. Signing devices from major hardware vendors do not parse witness data for inscription envelopes, meaning they can approve transactions that spend inscribed satoshis without any warning to the operator. MPC protocols that fragment key shares across signers have no mechanism to preserve the ordinal position of a specific satoshi through a reshare event, effectively losing the asset's identity. Collaborative PSBT construction, where multiple parties contribute inputs and outputs, routinely misassigns change outputs in ways that break Runes token balances tracked by off-chain indexers. These are not edge cases; they are the default behavior of systems that treat all satoshis as equal.
Recovery procedures compound the risk. Standard multisig recovery paths—designed to sweep all funds to a new key set after a compromise or key loss—will consolidate every UTXO, including those holding inscriptions and Runes, into a single output. The indexer sees this as a transfer or burn event, and the original asset location is lost. For Runes, the protocol's UTXO-based accounting means that a token balance can be atomically destroyed if the UTXO holding it is spent in a way that does not explicitly construct a valid Runes transfer. Custody providers and institutional teams operating without an inscription-aware UTXO management policy are one automated consolidation away from an irreversible loss event.
Chainscore Labs provides the protocol-level review that custody infrastructure teams need to map these failure modes onto their specific signing, key management, and transaction construction architectures. This includes auditing PSBT construction logic for Runes compatibility, verifying that hardware signing devices can be configured to flag inscription-bearing UTXOs, and stress-testing recovery procedures against the full set of meta-protocol state transitions. Teams holding material Ordinals or Runes positions in collaborative custody should treat their current setup as insecure by default until proven otherwise.
MULTISIG AND COLLABORATIVE CUSTODY FAILURE MODES
Incident Snapshot
A structured overview of the specific technical failure modes, affected actors, and required actions when multisig, MPC, or collaborative custody setups interact with Ordinals and Runes.
| Area | What changes | Who is affected | Action |
|---|---|---|---|
Signing Device Recognition | Hardware security modules (HSMs) and hardware wallets do not parse witness data containing inscription envelopes or Runes runestones, presenting a blind signing risk. | Institutional custodians, MPC wallet providers, high-net-worth individuals using hardware multisig. | Verify that all signing devices in the quorum can decode and display Ordinals/Runes transaction intent before approving PSBTs. |
PSBT Construction | Collaborative custody and multisig coordinators often strip or malform non-standard witness data when constructing Partially Signed Bitcoin Transactions, destroying the inscription or Runes transfer. | Wallet coordinators (Caravan, Sparrow, Nunchuk), exchange withdrawal systems, custom custody platforms. | Audit the PSBT construction and finalization logic to ensure witness integrity for non-standard transactions. Test with real inscribed UTXOs. |
UTXO Selection Logic | Standard coin-selection algorithms in multisig wallets do not distinguish between inscribed satoshis, Runes-bearing UTXOs, and standard BTC, leading to accidental spending of digital assets as fees. | Collaborative custody providers, DAO treasuries, OTC desks using multisig. | Implement and test ordinal-aware and Runes-aware coin selection. Integrate indexer data to flag and lock UTXOs containing non-BTC assets. |
Recovery and Key Rotation | Standard multisig recovery procedures (e.g., sweeping funds to a new quorum) treat all UTXOs as fungible BTC, causing irreversible loss of Ordinals and Runes during a security migration. | Security teams performing key rotation, disaster recovery planners, institutional custody operators. | Develop a non-fungible asset recovery playbook. Recovery transactions must be constructed manually with indexer awareness to preserve asset-bearing UTXOs. |
Fee Management | Collaborative fee bumping (CPFP/RBF) by one member of a quorum can inadvertently consume an inscribed satoshi or Runes-bearing UTXO if the wallet is not asset-aware. | Multisig participants, Lightning Network channel factories using multisig, statechain operators. | Disable automated fee bumping for wallets holding non-BTC assets. Require manual, asset-aware construction for any child-pays-for-parent transaction. |
Indexer Dependency | Multisig wallets that integrate an indexer to display balances introduce a new failure mode: a quorum signs a transaction based on stale or incorrect indexer state, leading to an unintended transfer. | Institutional investors, fund administrators, any team using a multisig with a 'portfolio view'. | Implement a transaction simulation step that verifies the final on-chain state change against the intended asset transfer before collecting signatures. |
Change Output Handling | Collaborative custody software may incorrectly assign an inscribed satoshi or Runes UTXO to a change address, commingling it with fungible BTC and making future controlled spending difficult. | Wallet developers, exchange hot wallet systems, payment processors integrating multisig. | Review change output logic to ensure asset-bearing UTXOs are returned to a controlled, marked address and not mixed with standard BTC change. |
technical-context
HOW MULTISIG AND MPC WALLETS DESTROY INSCRIPTIONS
Technical Mechanism of Failure
The core failure mode occurs when collaborative custody systems treat inscription-bearing UTXOs as generic Bitcoin, stripping witness data or constructing invalid PSBTs that permanently burn Ordinals and Runes.
The fundamental incompatibility between collaborative custody architectures and the Ordinals/Runes meta-protocols stems from a single operational truth: these assets are not recorded in the UTXO set itself but in the witness data of the transaction that created them. Standard multisig and MPC wallet implementations, designed exclusively for Bitcoin's value-transfer function, have no awareness of witness-data significance. When a signing device or MPC node participates in a transaction that spends an inscription-bearing UTXO, it typically validates only the output amounts and script conditions—not the preservation of the witness envelope that defines the digital artifact. The result is a transaction that is valid at the Bitcoin consensus layer but catastrophic at the meta-protocol layer: the inscription is destroyed, the Runes balance is obliterated, and the asset ceases to exist according to every indexer.
The failure manifests through several distinct technical vectors. In PSBT-based multisig workflows, a coordinator constructs a transaction spending an inscribed UTXO and distributes it to signers. If any signer's device does not recognize the inscription envelope in the witness stack, it may strip or reorder witness data during signing, producing a finalized transaction that omits the ordinal payload. In MPC protocols like FROST or GG20, the signing process distributes key shares across nodes that collaboratively produce a Schnorr or ECDSA signature. These nodes typically operate on a transaction digest, not the full witness data, and the MPC protocol's message format may not include fields for preserving arbitrary witness structures. A coordinator that fails to explicitly include the full witness commitment in the pre-signing round will produce a valid signature over a transaction that has silently dropped the inscription. In hardware security modules (HSMs) used by institutional custody providers, the firmware's transaction parser may reject or truncate witness data that exceeds expected size limits, causing signing failures or, worse, producing a sanitized transaction that still meets the HSM's policy rules.
Recovery scenarios amplify these risks. When a multisig quorum must perform an emergency key rotation or recover funds from a compromised signer, the urgency of the operation often leads teams to use generic Bitcoin recovery tools that have no concept of inscription safety. A standard bitcoin-cli command or a hardware wallet's recovery interface will select UTXOs by value alone, sweeping inscribed satoshis into fee pools or consolidating them into change outputs where the witness data is permanently lost. For Runes, the danger is equally acute: a UTXO holding a Runes balance appears as a standard Bitcoin UTXO with a dust value, making it a prime target for automated consolidation routines that destroy the token balance. Custody providers and institutional teams must implement ordinal-aware UTXO locking, witness-preserving PSBT construction, and MPC protocol extensions that treat inscription data as a first-class security parameter—not an opaque blob to be discarded.
IMPACT ANALYSIS
Affected Systems and Actors
Institutional Custody and MPC Wallets
Multisig and MPC providers face the highest risk when their signing and UTXO selection logic is not inscription-aware. The primary failure mode is a signing device or coordinator treating an inscription envelope as arbitrary witness data and either stripping it during transaction construction or failing to sign due to unrecognized data patterns.
Action Items:
- Audit PSBT construction to ensure witness data is preserved intact.
- Verify that all signing devices in the quorum can parse and consent to non-standard witness scripts.
- Implement UTXO locking mechanisms to prevent accidental spending of inscribed satoshis as fees.
- Test recovery procedures with inscribed UTXOs to confirm assets survive key rotation and disaster recovery workflows.
Chainscore Labs can conduct a targeted review of your multisig transaction builder and signing ceremony for inscription and Runes compatibility.
implementation-impact
CUSTODY RISK ASSESSMENT
Operational Impact and Failure Scenarios
Specific failure modes when multisig or MPC wallets interact with inscribed satoshis or Runes-bearing UTXOs, and the operational controls required to prevent permanent asset loss.
01
Signing Device Blindness to Inscription Envelopes
Most hardware security modules (HSMs) and hardware wallets parse transactions as standard Bitcoin transfers. They do not recognize witness data containing inscription envelopes or Runes protocol messages. A quorum of signers can approve a transaction that spends an inscribed satoshi as a fee or consolidates a Runes-bearing UTXO into a standard output, permanently destroying the digital artifact. Custody teams must implement pre-signing checks that decode witness data and flag transactions involving non-standard outputs before they reach the signing threshold.
02
Incorrect PSBT Construction in Collaborative Custody
Partially Signed Bitcoin Transactions (PSBTs) used in multisig workflows often strip or reorder witness data during the signing round. An inscription envelope or Runes protocol message embedded in the witness can be corrupted, dropped, or invalidated when passed between signers. The resulting transaction may confirm but with a malformed inscription that indexers reject, or with Runes transfers that fail silently. Custody providers must validate PSBT integrity at each signing step and test their PSBT library against inscription-bearing transactions specifically.
03
Recovery Key Ceremony Risks for Inscribed UTXOs
Standard multisig recovery procedures assume all UTXOs are fungible satoshis. During a key rotation or shard recovery ceremony, the recovery transaction may sweep all funds to a new address without UTXO-level selection controls. This can consolidate inscribed satoshis into a single output, burning the inscription, or destroy Runes balances by merging them into an unrecognized output. Institutional custody teams must design inscription-aware recovery paths that preserve specific UTXOs or include a pre-recovery inventory step that identifies and protects non-fungible assets.
04
MPC Share Refresh and Address Rotation Conflicts
MPC protocols that periodically refresh key shares or rotate deposit addresses can orphan inscribed satoshis held at old addresses. If the MPC engine treats all UTXOs as spendable by any refreshed key share, an automated consolidation sweep may spend an inscription as a fee or merge Runes tokens into an unmanaged output. Custody operators must maintain a registry of addresses holding non-fungible assets and exclude them from automated key rotation sweeps until an explicit, inscription-aware transfer is executed.
05
Fee Estimation Failures on Inscription-Bearing UTXOs
Transactions spending inscribed satoshis or Runes UTXOs are often larger than standard Bitcoin transactions due to witness data. Multisig fee estimation logic that assumes standard input sizes will underpay fees, causing transactions to stall in the mempool. In collaborative custody, a stalled transaction exposes the partially signed state to all signers for an extended period, increasing the risk of nonce reuse or external monitoring. Custody providers must calibrate fee estimation to account for witness data size and implement timeouts on partially signed states.
06
Chainscore Labs Custody Security Review
Chainscore Labs provides a targeted security review for institutional custody teams handling Ordinals and Runes. The engagement covers PSBT construction validation, signing device compatibility testing, inscription-aware UTXO selection logic, recovery ceremony playbooks, and MPC key rotation safeguards. Teams receive a detailed threat model and operational checklist specific to their multisig or MPC architecture. Contact Chainscore Labs to schedule a custody workflow assessment before a loss event forces a reactive review.
MULTISIG AND COLLABORATIVE CUSTODY FAILURE MODES
Risk Assessment Matrix
Operational risks and failure modes when holding inscriptions or Runes in multisig, MPC, or collaborative custody setups. Use this matrix to identify gaps in signing device awareness, PSBT construction, and recovery procedures.
| Risk Area | Failure Mode | Affected Actors | Mitigation Action |
|---|---|---|---|
Signing Device Blindness | Hardware security modules and signing devices do not parse witness data, displaying only a raw transaction hash. Signers approve a transfer without knowing an inscribed satoshi or Runes UTXO is being moved. | Custodians, MPC validators, institutional treasury operators | Implement pre-signing transaction simulation that decodes witness envelopes and displays asset details to all quorum members. |
PSBT Construction Errors | Collaborative custody software constructs a Partially Signed Bitcoin Transaction that mishandles change outputs, inadvertently placing an inscribed satoshi into a fee output or consolidating a Runes-bearing UTXO. | Wallet developers, exchange operations teams, protocol treasuries | Review PSBT output construction logic to ensure ordinal-aware coin selection and validate change output placement against the canonical indexer state before signing. |
Recovery Key Ceremony Risk | During a disaster recovery or key rotation ceremony, the recovery transaction is built without indexer awareness, spending inscribed satoshis as standard BTC fees and permanently burning the assets. | Institutional custodians, disaster recovery teams, security auditors | Integrate indexer balance checks into recovery playbooks. Rehearse recovery transactions on testnet with simulated inscribed UTXOs to validate asset preservation. |
Quorum Policy Gap | A multisig policy enforces spending limits in BTC terms but has no logic to prevent a single signer from initiating a transfer that moves a high-value inscription alongside a small BTC amount. | Governance delegates, risk teams, compliance officers | Define asset-aware spending policies that require additional quorum approval for transactions involving UTXOs flagged as containing inscriptions or Runes by a trusted indexer. |
Indexer Dependency During Signing | The collaborative signing process relies on a single indexer API to identify which UTXOs hold assets. Indexer lag, state divergence, or an API outage causes the signing interface to mislabel or omit asset holdings. | Infrastructure teams, MPC node operators, wallet UX designers | Use multiple independent indexer sources for asset identification during the signing flow. Implement a circuit breaker that halts signing if indexer state is inconsistent. |
Change Address Poisoning | An attacker sends a dust UTXO containing a malicious inscription to a known multisig address. During a subsequent spend, the wallet's coin selection algorithm picks this UTXO, and the signing interface fails to flag the unintended asset movement. | Custodial wallet operators, institutional treasury managers | Implement UTXO locking and tagging within the wallet infrastructure to exclude unknown or unverified inscribed UTXOs from automatic coin selection. |
Cross-Chain Settlement Failure | A multisig-controlled UTXO containing a Runes token is used in an atomic swap or bridge deposit. The Bitcoin-side signing completes, but the counterparty chain's indexer fails to recognize the Runes transfer, locking the asset. | Bridge operators, cross-chain protocol teams, liquidity providers | Conduct end-to-end testing of the settlement path with both Bitcoin and counterparty indexers. Implement a manual recovery path for multisig signers to reclaim assets if the bridge minting fails. |
MULTISIG AND COLLABORATIVE CUSTODY HARDENING
Remediation and Prevention Checklist
A structured checklist for custody providers, institutional teams, and wallet developers to audit their multisig or MPC implementation for safe handling of Ordinals and Runes. Each item identifies a specific failure mode, explains the operational risk, and defines the signal or artifact that confirms readiness.
What to check: Confirm that every hardware security module (HSM) or signing device in the quorum correctly parses and displays witness data containing inscription envelopes or Runes protocol messages before signing.
Why it matters: Standard multisig devices often treat witness data as opaque. A device may sign a transaction that spends an inscribed satoshi as a fee or misinterprets a Runes transfer, causing permanent asset loss without operator awareness.
Readiness signal: A test PSBT containing a dummy inscription envelope is presented to each signing device. The device UI must display a clear warning identifying the presence of non-standard witness data and the specific UTXO at risk.
resource-links
CANONICAL SPECIFICATIONS AND OPERATOR REFERENCES
Source Resources and Further Reading
Use these resources to validate inscription-aware coin selection, PSBT construction, signer behavior, and Runes handling across multisig or MPC custody workflows. Test against the exact wallet, indexer, and signing-device versions deployed in production.
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.
MULTISIG INSCRIPTION RISK FAQ
Frequently Asked Questions
Common questions from custody providers and institutional teams about the specific failure modes when using multisig or MPC wallets to hold Ordinals or Runes.
Most multisig signing devices and coordinator software were designed before the Ordinals and Runes meta-protocols existed. They do not parse witness data for ord envelope patterns or OP_RETURN Runes protocol messages. The assets exist on-chain, but the wallet's indexer or local parser is not looking for them.
What to check:
- Whether your wallet's backend indexer supports the specific inscription envelope format or Runes protocol message you received.
- If the signing devices strip or fail to return witness data during the transaction signing flow, preventing the coordinator from identifying the asset.
- Whether the wallet's UTXO selection logic treats all satoshis as fungible, hiding the presence of inscribed or Runes-bearing outputs.
Signal of readiness: The wallet's interface shows a distinct asset view for Ordinals or Runes, and its coin control features allow you to freeze or label specific UTXOs.
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.