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
SendtransactionFormat: "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:
3. Handle Lookup-Table Setup
Inspectreadiness.status before sending business transactions:
ready: executetransactionsin order, confirming dependencies independsOnbefore 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 thanminimumSlotExclusivewhen supplied. Lookup-table addresses must be usable before recompiling.setup_requiredwith no transactions: the table may still be warming up. This is not an empty successful business operation.
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.
