Sale PSBT Construction
ORD.NET sale transactions are snipe protected and fully self custodial.
To achieve this, ORD.NET assigns anchor UTXOs to every listing and sale, built around a seller-controlled 2-of-2 passthrough output shared between the seller and ORD.NET.
Listing
Section titled “Listing”When a seller lists an inscription for sale, ORD.NET collects three PSBT signatures from the seller:
TX1moves the inscription from the seller wallet into the 2-of-2 passthrough output.TX2spends the passthrough output as part of the sale transaction.TX3is a presigned recovery transaction that spends the passthrough output back to the seller.
Sale path
Section titled “Sale path”The seller signs TX2 with SIGHASH_SINGLE | SIGHASH_ANYONECANPAY, which locks in the seller
payment and the exact amount they will receive. That payment cannot be changed without invalidating
the signature.
This is similar to how inscription sale PSBTs have worked historically. The difference is that
ORD.NET also signs the inscription input with SIGHASH_DEFAULT, which commits to
the full sale transaction. That locks in the remaining inputs and outputs, preventing the seller
signature from being reused in a different transaction and blocking mempool RBF sniping.
Neither buyer nor seller has to trust ORD.NET with custody or pricing. The seller’s signature enforces the payment amount, and ORD.NET’s signature enforces the finality of the sale transaction.
Recovery path
Section titled “Recovery path”If the buyer cancels the sale transaction while it’s pending, ORD.NET
automatically RBFs TX1 by spending the anchor UTXO assigned to the listing, invalidating the
transfer before the inscription moves into the passthrough output.
TX3 exists to make recovery easy in the unlikely event that the inscription moves into the 2-of-2
passthrough output without an attached sale.
When a buyer purchases an inscription, ORD.NET constructs the sale transaction
using the inscription output from the seller’s TX1.
The sale transaction must include the intended seller payment so that it satisfies the seller’s
SIGHASH_SINGLE | SIGHASH_ANYONECANPAY signature conditions.
ORD.NET signs the inscription input with SIGHASH_DEFAULT, committing to the
complete transaction. This means the seller payment, buyer inputs, buyer outputs, and sale structure
are all fixed before broadcast.
TX1 — listing transaction:
TX2 — sale transaction:
The buyer only signs the final sale transaction. As a result, the buyer can purchase one inscription or sweep multiple inscriptions with a single transaction signature flow.
The marketplace fee output is split into two to land the inscription at the correct sat offset for the buyer. The sale transaction also creates the same number of new anchor UTXOs as it consumes.
Anchor UTXOs
Section titled “Anchor UTXOs”ORD.NET includes anchor UTXOs in the seller’s TX1 so the inscription can move
from the seller wallet into the 2-of-2 passthrough output at the minimum mempool relay fee rate of
0.1 sat/vB.
The change output from TX1, plus an additional anchor UTXO in the sale transaction, act as bump
UTXOs. This removes any buyer wallet preparation step, since the buyer doesn’t need to provide bump
UTXOs.
Passthrough Tapscript
Section titled “Passthrough Tapscript”The taproot descriptor for the passthrough output:
tr( <seller_pubkey>, multi_a(2, <seller_pubkey>, <ordnet_pubkey>))ORD.NET public key:
d2dc3222298e2a5f4e1c7d702fae2bcf7821cc0a095a478b95c62195b0df7398Key path spend: the seller can unilaterally spend the output through the taproot key path using the seller public key.
Script path spend: the intended sale path is the taproot script path. This requires signatures from both the seller and ORD.NET. This is the coordinated sale path used when a buyer purchases the inscription.