Skip to main content
The Transaction API prepares Solana transactions for Swig wallet creation, transfers, swaps, x402 payments, and custom instruction sets. It does not replace required application signatures. Responses include explicit signature requests for embedded secp256r1 and secp256k1 authorization; native Ed25519 signers are represented in the serialized Solana transaction instead.

Supported preparation routes

Preparation requests are not retried automatically. A replay can duplicate work, so decide per call whether repeating is correct. The general add-role route attaches a supported authority and one or more typed actions to an existing Swig. The ParticipantSet routes create one threshold set, attach it through that general route, and compile detached member approvals into a simulated transaction. See Add Roles for the general role flow and requester constraints, or Participant Sets for the complete threshold lifecycle, member challenge rules, and current operation support.

Auth

Use an API key:

Common request fields

The x402 preparation route takes its fee payer from the selected offer’s extra.feePayer in paymentRequired.accepts. This route has no top-level feePayer request field.

Prepared transaction response

Most endpoints return a prepared transaction or a response containing prepared transactions. Each signature request carries scheme, signer, messageHash, slot, and counter. The signer is encoded for its signature scheme, and messageHash is the hex-encoded message to sign. An empty array does not prove that the transaction needs no application signature; inspect the Solana transaction’s required signer set for native Ed25519 authorities and other transaction-level signers.

Rent claimers

These API-key routes read and configure the rent recipient on a V2 Swig. Use the Swig config PDA as swig_address or swigAddress.

Read the recipient

GET /transaction/wallet/{swig_address}/rent-claimer?network=NETWORK_MAINNET network is required and accepts NETWORK_MAINNET or NETWORK_DEVNET. The backend reads finalized chain state and returns:
When a valid config has no recipient, the optional rentClaimer field is absent. Missing accounts, malformed or unsupported state, and RPC failures return errors. A requester authority is not needed for this read.

Prepare the setter

POST /transaction/wallet/rent-claimer/set
Every field shown is required. The requester must match a direct Ed25519 role with All or CloseSwigAuthority; ManageAuthority alone is insufficient. The recipient must differ from the zero public key, config PDA, and wallet PDA. An existing recipient is rejected even when it matches the requested value. The response wraps an unsigned prepared transaction:
Both the requester and fee payer must provide native transaction signatures, or one signature when the keys coincide. The backend fetches finalized state and a fresh blockhash, then prepares the transaction. The application signs, submits, and confirms it. Preparation does not set the recipient; the program enforces the set-once rule when the transaction executes. See Rent Claimers for TypeScript examples.

Prepare a batch

POST /transaction/prepare/batch batches one or more supported operations for an existing Swig.

Prepare custom instructions

POST /transaction/prepare/custom builds one prepared Swig transaction from the Solana instructions supplied by the application.
The response is prepared only. The application still supplies every embedded signature request and transaction-level signer, then chooses direct or sponsored submission.

Create a wallet

POST /transaction/wallet/create

Transfer SOL

POST /transaction/transfer/sol

Transfer SPL token

POST /transaction/transfer/spl-token

Jupiter swap

POST /transaction/swap/jupiter
Optional Jupiter controls:

Prepare an x402 payment

POST /transaction/payment/x402/prepare prepares a Swig token-payment transaction from a decoded x402 version 2 PaymentRequired challenge. It supports the exact payment scheme on Solana. This route supports Ed25519 and secp256r1 requester authorities only. Decode the resource provider’s PAYMENT-REQUIRED header with your x402 library’s header decoder, or Base64-decode the header value and parse its JSON. Pass the resulting object as paymentRequired.
The selected offer uses:
  • amount as the payment amount in atomic token units
  • asset as the token mint address
  • payTo as the destination owner rather than its token account
  • extra.feePayer as the facilitator fee payer
An eligible offer must use the exact scheme and the requested Solana network. Its amount must be a canonical positive integer string that fits in an unsigned 64-bit integer. asset, payTo, and extra.feePayer must be valid Solana public keys. extra is required, maxTimeoutSeconds must be a positive unsigned 32-bit integer, and an optional memo must not exceed 256 UTF-8 bytes. The network field inside each offer uses a CAIP-2 identifier. In this example, solana:EtWTRABZaYq6iMfeYKouRu166VU2xqa1 corresponds to NETWORK_DEVNET in the request’s top-level network field. When acceptedIndex is omitted, Swig selects the first eligible offer on the Solana network specified by the request’s top-level network. With an explicit index, that offer must match the requested network; Swig returns an error instead of selecting another offer. Offer selection evaluates these request fields only. Account and balance validation happens after selection; if that validation fails, Swig does not try the next offer. On success, acceptedIndex is always present, including when the selected offer is at index 0:
See x402 Payments for decoding the resource response, signing the prepared transaction, creating the PAYMENT-SIGNATURE header, and retrying the protected request.

After preparation

For most prepared transactions, your application supplies every embedded signature request and transaction-level signer, then submits the transactions in the returned order—directly or through the Paymaster API. For x402 payments, sign the prepared transaction, create the PAYMENT-SIGNATURE header, and retry the protected resource request. The resource provider’s facilitator verifies and settles the transaction. If policyId is omitted on wallet creation, initialUser is required and the API creates a wallet policy for the caller’s organization.