Skip to main content
Custom-quote write endpoints return a transaction plan: an ordered set of transactions with signer, lifetime, fee, and readiness information. Building a plan does not submit it or complete the operation.

Find the Plan

Check HTTP errors and success before reading response. These plans use base64 transaction bytes. Existing endpoints can retain other response shapes and base58 encoding; do not feed their responses through the plan parser.

1. Select a Transaction Format

Send transactionFormat: "v0" for v0 transactions with lookup tables when needed. These plan endpoints also default to v0 if you omit the field. Request "v1" only when your signer, serializer, and RPC transport support V1 throughout the operation. An unsupported request fails rather than silently changing formats. The plan’s contractVersion: 1 versions the response contract; it does not mean its transactions are V1. For V1, use a V1-capable transaction implementation, such as Solana Kit 8.0.0, and preserve all message bytes and existing signatures. Do not deserialize V1 with web3.js VersionedTransaction. Send and simulate RPC transactions using base64.

2. Review Token Transfer-Fee Limits

feeLimits bounds a token’s transfer-fee schedule parameters. It is separate from trading fees, tips, and SOL transaction fees. For example:
This accepts at most a 50 BPS transfer-fee rate and a cap of 1,000,000 raw quote units. The assertion checks both parameters conservatively; it can reject a larger cap even when a particular small transfer would cost less. It is not a promise of total fees across the plan or a guaranteed minimum receipt. When omitted, supported plan builders use the observed active schedule and return the signed limits in the plan. Review these values before signing. A worse execution-time schedule fails the bounded transaction. Rebuilding with higher limits requires a new decision from the signer.

3. Handle Lookup-Table Setup

Inspect readiness.status before sending business transactions:
  • ready: execute transactions in order, confirming dependencies in dependsOn before proceeding.
  • setup_required: execute only the returned lookup-table setup stages. Confirm them, fetch the table state, and wait until the confirmed slot is greater than minimumSlotExclusive when supplied. Lookup-table addresses must be usable before recompiling.
  • setup_required with no transactions: the table may still be warming up. This is not an empty successful business operation.
Call the original endpoint again with the same business arguments and the returned readiness.lookupTables included in additionalLookupTables. Retain any tables you already supplied. If readiness is still pending, wait and refetch; do not resend already confirmed setup stages. Setup is separate from config creation, launch, or claiming. A completed setup transaction is not proof that fees were claimed or a token launched.

4. Co-Sign and Submit Each Stage

Each stage identifies its format, base64 bytes, required signer addresses, message hash, and blockhash lifetime. requiredSigners includes all required signers, including signatures the server may already have supplied. Add only missing signatures using the appropriate wallets, without rebuilding the message or replacing existing signatures. For a Node.js integration using v0, the following helper submits one stage with one additional wallet signer. Call it in plan order only after the readiness and dependency checks above. It intentionally stops on errors instead of automatically rebuilding or sending later stages.
Keep the returned resource budgets intact. V0 priority fees use micro-lamports per compute unit; V1 priority fees use total lamports. These units are not interchangeable.

5. Resume Without Duplicating Work

Persist the original request, stage IDs, signed bytes, and signatures. On timeout or RPC uncertainty, stop sending later stages and check the original signature history and actual on-chain state. A missing status response or expired blockhash alone does not prove the transaction never executed. Resume only the unresolved work after reconciliation. Do not change format, blockhash, or fee ceilings merely to retry an uncertain send. For claim-all interfaces, clearly unavailable positions can be reported and skipped; an uncertain submission must stop further sending until resolved.