A commitment is a per-order PDA holding your escrowed payment until a keeper fills it, you cancel it, or it expires.
Lifecycle
Every commitment lives in one of four states. Terminal states close the on-chain account — meaning the PDA is reclaimed and the rent comes back to whoever it was deposited by.
| Active | Created and waiting. Funds are escrowed in the PaymentVault PDA. |
| Executed | Filled by a keeper. Target tokens are now in your wallet ATA. Account closed. |
| Cancelled | You called cancel_commitment. Payment refunded; account closed. |
| Expired | Past expiry_ts. Any keeper can call expire_commitment to refund you (and reclaim the rent). |
The PDA layout
Each commitment is its own Program-Derived Address — no shared state with other orders. The seeds are ["commitment", owner, nonce]. The nonce is set client-side at create-time (typically Date.now()) so the same owner can keep many open orders without collision.
nonce is set client-side (typically Date.now()) so the same owner can keep many open orders without seed collision.The payment vault
A second PDA, ["vault", commitment], owns a fresh ATA for the payment mint. This is where escrowed funds actually live — the commitment account itself only holds rent + the keeper bounty (in lamports stored on the account, withdrawable only by the program on execute or refunded to the owner on cancel).
Splitting commitment state from the token vault means standard explorers (Solscan, Solana FM) render the balance correctly and the Jupiter CPI on execute_commitment can use the PaymentVault PDA as the swap user-authority via signer seeds.
Fields
| owner | Pubkey of the commitment creator. Only this signer can cancel. |
| target_mint | The mint you want to buy. Can be SPL Token or Token-2022 (with safe extensions only). |
| payment_mint | USDC, USDT, or wSOL. The program rejects anything else with UnsupportedPaymentMint. |
| payment_amount | u64. Raw token amount escrowed (i.e. lamports for wSOL, micro-USDC for USDC). |
| max_price | u128 fixed-point at 1e18 scale. effective_price = payment * 1e18 / received, rounded up; reverts if > max_price. |
| min_fill | u64 raw. The execution reverts if Jupiter delivers fewer target tokens than this. |
| keeper_bounty | u64 lamports. Paid out of the commitment account on execute. Refunded to owner on cancel/expire. |
| target_decimals | u8. The decimals you expect the target mint to have, declared up front so a commitment can be created before the mint exists. Verified at execute time — a mismatch reverts with DecimalsMismatch. |
| user_jito_tip_lamports | u64 lamports. Optional Jito tip the keeper forwards when landing a pump.fun fill via a bundle, for fill priority on launches. Deducted from escrow on success; 0 disables it. |
| trigger | An enum: JupiterRoutable, TimeOnly, or JupiterRoutableAfter. See Triggers. |
| expiry_ts | i64 unix seconds. After this time, anyone can call expire_commitment. |
| status | Active | Executed | Cancelled | Expired. |
Instructions
create_commitment
Initialises the Commitment + PaymentVault PDAs, pulls payment_amount from the owner's ATA into the vault, and validates the target mint against the Token-2022 safety allowlist. Only the owner signs.
execute_commitment
Permissionless. Any keeper calls this with a Jupiter swap payload. The program:
- Validates the keeper-supplied Jupiter program id + instruction discriminator (only
sharedAccountsRouteis permitted). - Re-verifies the target mint hasn't grown an unsafe Token-2022 extension since create time.
- Skims 20 bps off the payment leg to the treasury ATA via a signed transfer.
- Snapshots the owner's target-token balance.
- CPIs into Jupiter with the PaymentVault PDA as the swap user-authority.
- Reloads accounts and asserts tokens_received ≥ min_fill and effective_price ≤ max_price.
- Pays the keeper bounty and closes the commitment + vault.
cancel_commitment
Owner-signed. Refunds the escrowed payment, closes the vault and the commitment account. Owner receives both the refund and the reclaimed rent.
expire_commitment
Permissionless after expiry_ts. Refunds the owner. Bounty refunds to the owner too (cleanup is its own implicit reward via the reclaimed rent, which goes to the keeper).