PSBT Race Condition Exploits in Ordinals Marketplaces

Partially Signed Bitcoin Transactions (PSBTs) are the standard coordination mechanism for trustless Ordinals and Runes trades, allowing a buyer and seller to collaboratively construct a transaction without exposing private keys to a marketplace. However, the asynchronous nature of PSBT signing creates a critical race condition window: after a counterparty signs but before the transaction is broadcast and confirmed, a malicious actor can manipulate the transaction's inputs, outputs, or fee structure to alter the agreed-upon trade terms. This class of exploit has been a recurring source of financial loss across Ordinals marketplaces, with attackers using techniques ranging from simple front-running to sophisticated replacement cycling.

The core vulnerability lies in the PSBT workflow itself. A typical marketplace trade involves a seller signing a PSBT to list an inscription, a buyer signing to purchase it, and a marketplace or third-party relayer finalizing and broadcasting the transaction. At each step, an unsigned or partially signed transaction exists in a malleable state. Attackers exploit this by monitoring the mempool for partially signed trades, then constructing competing transactions with higher fees, altered outputs, or additional inputs that divert the inscription or Runes UTXO to their own address. The introduction of time-locked PSBTs and anti-exfiltration commitments has mitigated some vectors, but the fundamental tension between collaborative signing and atomic finality remains unresolved.

Marketplace security teams must treat PSBT construction as a security-critical component, not a simple serialization format. Effective countermeasures require a layered defense: enforcing strict input and output validation before signing, implementing time-locked refund paths to limit exposure, using anti-exfiltration protocols to prevent nonce reuse, and monitoring the mempool for competing transactions that target pending trades. Wallet developers face the parallel challenge of presenting PSBT contents to users in a human-readable format that enables informed signing decisions. Chainscore Labs provides integration review services that assess a marketplace's entire PSBT lifecycle—from construction and signing to broadcast and confirmation—against known race condition attack patterns and emerging exploit techniques.

PSBT race condition exploits in Ordinals and Runes marketplaces exploit the asynchronous nature of Partially Signed Bitcoin Transactions. In a typical marketplace flow, a seller constructs a PSBT listing an inscription or Runes UTXO for sale, signs their input, and passes the incomplete transaction to a buyer. The buyer then adds their own inputs and outputs—including the payment and any marketplace fees—signs their portion, and broadcasts the final transaction. The vulnerability exists because the seller's signature is committed to a specific transaction structure before the buyer's actions are finalized, but the transaction is not broadcast until the buyer completes their side. An attacker acting as a buyer can leverage this window to alter the transaction's fee rate, change the destination of the payment output, or broadcast a conflicting transaction that spends the same UTXO under different terms.

The core exploit pattern often involves transaction replacement or fee manipulation. After receiving a signed PSBT from a seller, a malicious buyer can extract the seller's signature and construct a new, conflicting transaction that spends the same Ordinal or Runes UTXO—but to a different address or with a minimal fee. By broadcasting this alternative transaction with a higher fee using Replace-By-Fee (RBF), the attacker can have their version confirmed, effectively stealing the asset while the seller's original PSBT becomes invalid. A related variant exploits the lack of time-locks: a seller signs a PSBT without an expiration, and the attacker simply delays broadcasting until market conditions shift unfavorably for the seller, then either abandons the trade or demands renegotiation. In both cases, the seller's pre-signed commitment is weaponized against them because the PSBT lacked constraints on when and under what fee conditions the transaction could be finalized.

Countermeasures have evolved to include seller-imposed time-locks via nLockTime or OP_CHECKLOCKTIMEVERIFY, which make the signed transaction invalid after a specified block height, preventing indefinite holding attacks. Anti-exfiltration techniques, such as requiring the buyer to commit to their inputs and outputs before the seller signs, reduce the malleability surface. Some marketplace architectures have moved toward a dual-PSBT model where the seller signs only a cancelable offer, and a separate, co-signed transaction is constructed atomically only when a buyer locks in their terms. Despite these improvements, the underlying trust model remains fragile: the seller must still sign first in most non-custodial designs, and the security of the trade depends on the completeness of the PSBT validation logic in both the marketplace frontend and the user's wallet. Marketplace security teams and wallet developers should conduct an integration review to verify that their PSBT construction enforces strict time-locks, validates all output scripts before signing, and detects conflicting mempool transactions before presenting a PSBT for user approval.