This guide covers settling payments programmatically using the x84 SDK. Settlement verifies the payment, deducts the 3% protocol fee, transfers tokens, and creates a compressed receipt via Light Protocol.
Settlement modes
x84 supports three modes. Choose based on your trust model:
Prerequisites
Settlement uses Light Protocol for compressed receipts. You need an RPC provider that supports ZK Compression: Helius (recommended) or Triton.
Atomic settlement
The payer signs the transaction. Tokens move on-chain via CPI.
The settle function handles the full lifecycle: builds the instruction, fetches the Light Protocol validity proof, creates a VersionedTransaction with the address lookup table, signs, sends, confirms, and parses events.
Attestation settlement
The facilitator attests that payment happened off-chain. No tokens move on-chain.
The signer must be the protocol’s registered facilitator key stored in ProtocolConfig. Unauthorized callers get error code 6038 (FacilitatorRequired).
Delegated settlement
Uses a pre-approved budget. No per-request signature from the payer.
The program verifies all delegation constraints (active, owner_version, expiry, spend limits, allowed tokens, uses) before executing the transfer.
Low-level instruction builder
When you need the raw instruction to combine with other instructions in a custom transaction:
Settlement transactions require ~100-150K compute units for Light Protocol proof verification. Always include the computeBudgetIx. Removing it causes transactions to fail.
Parse settlement events
Query receipts
Receipts are compressed PDAs. Use a ZK Compression-compatible RPC to query them.
Fee structure
Every settlement deducts a protocol fee before the payee receives payment.