PSET lifecycle

Every mutating AMP2 operation (issue, send, reissue, burn) follows the same PSET pattern. Understanding this pattern is essential for both issuer and venue integrations.

What is a PSET

PSET stands for Partially Signed Elements Transaction. It is the Liquid equivalent of Bitcoin's PSBT (BIP 174). A PSET contains:

• Transaction inputs (UTXOs being spent)
• Transaction outputs (new UTXOs being created)
• Signature placeholders for each required signer
• Metadata about the transaction (fee rate, blinding data, etc.)

The PSET is serialized as base64 and passed between parties until all required signatures are collected.

The 5 step pattern

Every asset operation follows this sequence:

Step 1: Request the operation

Call the appropriate resource with operation parameters. AMP2 selects UTXOs, constructs the transaction, and returns an unsigned PSET.

Step 2: Receive unsigned PSET

AMP2 returns the PSET as a base64 encoded string. At this point, the PSET has zero signatures, so it cannot be broadcast.

Step 3: Sign locally

Sign the PSET with your own keys using LWK's SwSigner or equivalent:

let mut pset = pset_from_b64(&pset_str)?;
signer.sign(&mut pset)?;

This adds your signature to the PSET. The transaction still needs AMP2's cosignature.

Step 4: Request AMP2 cosigning

Send the client signed PSET to the /amp/wallet/sign resource. AMP2's HSM:

1. Validates the PSET: checks that inputs and outputs match the expected operation.
2. Checks restriction policies: for send operations, verifies that the destination wallets are whitelisted (if useToWhitelist is enabled), burn permission is valid, and no locks are violated.
3. Cosigns via HSM: if all checks pass, the HSM adds its secp256k1 signature.

If any policy check fails, the HSM refuses to sign and AMP2 returns an error. The transaction cannot proceed.

Step 5: Broadcast

Send the fully signed PSET to the /amp/wallet/broadcast resource. AMP2 finalizes the transaction and broadcasts it to the Liquid Network, returning the transaction ID (txid).

Note: PSET lifecycle visual: the five-step flow from request through cosigning to broadcast.

Why two signatures

The 2-of-2 signing model serves as a mutual control mechanism:

Neither the client nor AMP2 can unilaterally move assets. This provides defense in depth for regulated asset operations.

Operations that use the PSET flow

Error scenarios

Idempotency

PSET operations are not idempotent at the request level. Calling the issue endpoint twice creates two separate PSETs with different UTXO selections. However:

• Broadcasting the same fully signed PSET twice is safe (the network rejects duplicates).
• If a PSET fails at the sign or broadcast step, you should request a new PSET rather than retrying the old one, as UTXO state may have changed.

Related pages

• Asset Issuance: PSET flow for minting new assets
• Sending Assets: PSET flow for transfers
• Signing PSETs (Venue): LWK based PSET construction
• Architecture: how AMP2, HSM, and Liquid fit together