Skip to content
LogoLogo

16. Partially signed transactions (PST, wallet standard, not consensus)

A PST carries an unsigned transaction plus what signers need. It lets several parties (multisig co-signers, hardware or air-gapped signers, a policy co-signer, both sides of a swap) each add signatures without trusting one another. It follows BIP 174 / BIP 370 (PSBT), adapted to Arrekta. Vectors: vectors/pst.json. Text form: standard base64 of the binary.

16.1 Encoding

pst      = "dpst" 0xFF | u8 version (=1) | network magic (4) | u8 flags | varbytes tx (≤ 1,000,000)
           | #tx.inputs × input | #tx.outputs × output
input    = spent_output (asset 32 | amount u64 | lock) | varbytes redeem (≤ 65,536) | origins | sigs
output   = varbytes redeem (≤ 65,536) | origins
origins  = varint n (≤ 20) × [varbytes pubkey | varint d (≤ 10) × u32 child index]
sigs     = varint k (≤ 20) × [varbytes pubkey | varbytes signature]
flags    = bit 0: inputs may be added · bit 1: outputs may be added · other bits MUST be 0
  • tx is the full serialization (§5) with every witness empty.
  • redeem is what the lock commits to: the serialized public key for PUBKEY_HASH, the policy (§4) for MULTISIG_HASH, the policy encoding (§4.2) for POLICY, or empty when not known. Reserved lock kinds have no spending rules and can't appear as PST inputs (pst-reserved).
  • An origin says that pubkey is derived from the signer's master seed by the hardened child indices listed (§3.2). Example: m/9000'/0'/0'/1'/5' is encoded as [9000, 0, 0, 1, 5].

16.2 Rules (a decoder MUST reject violations; error codes in brackets)

  1. Magic, version 1, flags with only known bits, no trailing bytes [pst-magic, pst-version, pst-flags, pst-decode].
  2. The transaction has ≥ 1 input and every witness is empty [pst-coinbase, pst-witness].
  3. A spent output with a BURN lock is invalid [pst-burn].
  4. A non-empty redeem MUST hash to the lock, using the same check as witness verification (§4) [pst-redeem-mismatch, pst-redeem]. A BURN output carries no redeem data and no origins.
  5. Origins and signatures require redeem. Each pubkey MUST be a key named by redeem. The lists MUST be sorted strictly ascending by pubkey bytes, which forbids duplicates [pst-redeem-missing, pst-foreign-key, pst-order]. Path elements are < 2³¹.
  6. A PUBKEY_HASH input carries at most one signature. Signatures are non-empty.
  7. Inputs listed in tx.clawbacks carry no redeem data, origins or signatures [pst-clawback].
  8. If any signature is present, flags MUST be 0 [pst-flags]. The sighash commits to the whole transaction, so a signed PST can no longer change shape.

The decoder does not verify signatures. That is a separate step, run by combiners and finalizers.

16.3 Roles

  • Creator: wraps an unsigned transaction and the outputs it spends. It MAY set flags to leave inputs or outputs open. For an atomic swap, Alice offers asset A and Bob adds his inputs and outputs.
  • Constructor: appends inputs and outputs while the matching flag is set.
  • Updater: adds redeem and origins.
  • Signer: signs sighash(i) (§6.4) for each input whose redeem names one of its keys, then sets flags to 0. A signer SHOULD display, per asset, the amounts leaving, the change and the fee. An output counts as change only if one of its origins derives, from the signer's own seed, to a key named in the output's redeem. Rule 4 guarantees that redeem matches the lock, so a coordinator cannot pass off a lock it controls as the signer's change.
  • Combiner: merges PSTs of the same transaction (byte-identical tx and spent outputs, same network). It takes the union of redeem data, origins and signatures. It MUST verify every incoming signature. Conflicting redeem data is an error.
  • Finalizer: builds the witnesses. PUBKEY_HASH uses [pubkey, sig]. MULTISIG_HASH uses [policy, slots], taking the first m available signatures in policy key order. POLICY uses the first satisfiable branch (preorder), dissatisfying the others with empty items. Hashlock preimages are given to the finalizer locally and are never stored in the PST. Clawback inputs get an empty witness. The finalizer verifies each witness and outputs the signed transaction.

Why signers can trust spent outputs without a UTXO lookup: the sighash commits to the asset, amount and lock of every spent output. A coordinator that lies about any of them gets a signature over a different message, which the network rejects. The worst it can do is waste a signature, so the fee shown from the PST's spent outputs is trustworthy.