# PEARL HTLC Transactions ## Overview On the PEARL side, settlement is based on a Taproot lock and release model. The seller prepares a Taproot lock transaction and a Taproot release transaction for the known buyer. The release path is not generic: it is bound to the intended buyer output and protected by the seller's Taproot signature. Known buyer first, seller signature second. The seller does not sign a blank permission to send PEARL elsewhere. The seller signs the intended release transaction for the specific buyer, amount, and trade context. ## Required Inputs | Input | Purpose | | ----------------------------------- | ------------------------------------------- | | Seller PEARL funding UTXO(s) | Funds the PEARL lock | | Seller PEARL address/key | Authorizes the PEARL-side spend | | Buyer PEARL address | Final PEARL recipient | | Trade amount | PEARL amount to release | | Order/deal identifier | Links PEARL-side flow to OTC order | | Timeout/refund parameters | Defines recovery behavior | | Wallet-secured secret or commitment | Coordinates release and EVM claim lifecycle | | Network fee estimate | Builds valid PEARL transactions | ## Taproot Lock Transaction The Taproot lock transaction commits seller PEARL into the PEARL-side settlement path. It should only be signed after the buyer/order details are known, because the lock metadata and later release proof must link back to one current trade. A lock transaction should not be reusable across trades. At minimum, the wallet or signing flow should bind the lock to the current order/deal identifier, hashlock, amount, buyer destination, refund timing, and network. The lock output must be constructed so the expected release/refund logic can spend it: * release path: reveal the wallet-secured secret/proof and release PEARL through the intended Taproot release transaction; * refund path: allow seller recovery after the PEARL refund timeout if settlement does not complete. To verify before production release: low-level byte examples for script leaves, control blocks, witness layout, and exact field serialization should be checked against the current PEARL transaction rules before publishing byte-for-byte templates. ## Taproot Release Transaction The Taproot release transaction spends the PEARL lock output to the known buyer. The buyer output must be fixed before the seller signs. Before signing, the seller should verify: * buyer PEARL address; * PEARL amount; * fee handling; * lock outpoint; * order/deal identifier; * hashlock or wallet-secured secret commitment; * timeout/refund parameters; * network; * EVM escrow reference. The release transaction is safe to pre-sign because it is bound to the intended buyer and transaction data. The pre-signed release is not a reusable authorization. If the buyer output, amount, or signed release data changes, the seller signature should no longer validate for the intended release. `0x83` is the Taproot sighash byte used by the PEARL-side release signature. In Black Pearl Market's settlement model, it is part of the transaction-binding protection: the seller signs the intended release transaction, not a reusable permission to send PEARL elsewhere. In the current model, `0x83` corresponds to `SIGHASH_SINGLE | SIGHASH_ANYONECANPAY`. This binds the seller signature to the release input and corresponding buyer output, while allowing fee inputs and change outputs to be added around the release. Confirm the exact PEARL/Taproot sighash semantics against the chain implementation before publishing low-level byte-level examples. ## Why The Known Buyer Matters The buyer is known before the seller signs the release transaction. This is what makes the release flow safe: the seller is not signing a blank release. The seller signs a transaction that pays the specific buyer address and amount for the specific trade. Known buyer first, seller signature second. This is also why seller-side signing should not happen against incomplete trade context. A release signature created before the buyer destination is known would not provide the same safety property. ## Wallet-Secured Secret The secret is wallet-secured. Users should treat it as protocol-sensitive data and only use it through the official wallet or contract flow. The secret is generated and protected by the wallet/session flow. It coordinates release/claim behavior and can be used as proof that PEARL-side release conditions were satisfied. The secret should not be pasted into random websites or shared in chat. Support, admins, and public channels should never ask users for seed phrases or private keys. Users should not treat the wallet-secured secret as ordinary support data. It becomes useful to settlement only through the official release/claim flow or an explicit public reveal step required by the protocol. ## EVM Escrow Connection Buyer USDC is locked in the EVM escrow contract. PEARL-side release/proof makes the seller eligible to claim USDC from the contract-based USDC escrow, and the seller must claim within the seller claim window. The lifecycle has two legs: 1. USDC escrow on EVM. 2. PEARL release on the PEARL chain. If the seller does not complete the required steps in time, buyer refund can become available according to the EVM escrow rules. If the PEARL side times out first, the seller has the PEARL-side refund path according to the Taproot lock rules. ## Validation Checklist Before Signing * Correct buyer PEARL address * Correct PEARL amount * Correct order/deal ID * Correct lock outpoint * Correct timeout/refund parameters * Correct fees * Correct network * Correct destination output * Correct EVM escrow reference * No unexpected outputs * Transaction preview shown to user ## What To Show The User Wallet and app prompts should make the trade understandable before signing: * action type: PEARL lock, PEARL release, or PEARL refund; * buyer destination for a release; * seller address for a lock or refund; * PEARL amount; * fee estimate; * timeout or refund time; * order/deal identifier; * connected network; * warning that seed phrases and private keys must never be shared. ## Safety Model The seller does not sign a generic release. The buyer address is fixed, the amount is fixed, and the trade context is fixed before the seller release signature is created. The Taproot signature binds the seller to the intended release transaction. The EVM escrow prevents direct buyer-to-seller USDC payment. The wallet-secured secret/proof links PEARL-side completion to the seller's USDC claim path. This is the core protocol distinction: PEARL-side settlement is a public Taproot lock-release lifecycle paired with contract-based USDC escrow, not an off-chain promise or hidden automation step. --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://docs.blackpearlmarket.com/overview-2/pearl-htlc-transactions.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.