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 asswig_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:
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
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:
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.
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
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:
amountas the payment amount in atomic token unitsassetas the token mint addresspayToas the destination owner rather than its token accountextra.feePayeras the facilitator fee payer
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:
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 thePAYMENT-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.
