Submit and Sponsor Transactions

The Developer SDK prepares unsigned transactions and accepts application-signed transactions for submission. There are two submission models:

send directly through your own RPC path
sponsor submission through Swig’s paymaster

Signing happens in application-owned wallet or custody code first. Sponsoring does not replace it. If useful, the narrow signing helpers assemble an application-provided signature into the prepared transaction.

TypeScript

const submitted = await swig.transactions.sponsor({
  transaction: signedBase64Transaction,
  network: 'mainnet',
  idempotencyKey,
});

// submitted.requestId
// submitted.signature
// submitted.spentByPaymaster

from swig_developer_sdk import SponsorSignedTransactionArgs

submitted = await swig.transactions.sponsor(
    SponsorSignedTransactionArgs(
        transaction=signed_base64_transaction,
        network="mainnet",
        idempotency_key=idempotency_key,
    )
)

# submitted.request_id
# submitted.signature
# submitted.spent_by_paymaster

The SDK handles the base58 payload encoding the paymaster expects. The response carries the request id, the submitted signature, and what the paymaster spent. There is no status field. A returned signature means the Solana RPC accepted the transaction; it may still be pending and is not confirmation or finality. Track it through your RPC provider when your product needs either. For single-transaction sponsorship, network resolves from the call and then the client default. If neither is set, the paymaster defaults to mainnet.

Retry safely with an idempotency key

Sponsorship is the one POST the SDKs will retry, and only when you pass an idempotency key.

TypeScript

await swig.transactions.sponsor({
  transaction: signedBase64Transaction,
  network: 'mainnet',
  idempotencyKey: `sponsor:${orderId}`,
});

A matching retry returns the original paymaster response rather than spending again. Without a key, a failed sponsorship call is left to your app to decide about, because a blind replay could pay twice. Derive the key from something stable in your own domain — an order id, a payment id — not from a fresh random value per attempt. sponsorBundle / sponsor_bundle submits one to five signed transactions as a single bundle. Use it when several transactions must land together, such as the ordered plan returned by wallet.prepare(...).

TypeScript

const bundle = await swig.transactions.sponsorBundle({
  transactions: [signedFirstBase64, signedSecondBase64],
  network: 'mainnet',
  idempotencyKey,
});

// bundle.requestId
// bundle.bundleId
// bundle.signatures
// bundle.estimatedSpentByPaymaster

from swig_developer_sdk import SponsorSignedTransactionBundleArgs

bundle = await swig.transactions.sponsor_bundle(
    SponsorSignedTransactionBundleArgs(
        transactions=(signed_first_base64, signed_second_base64),
        network="mainnet",
        idempotency_key=idempotency_key,
    )
)

# bundle.request_id
# bundle.bundle_id
# bundle.signatures
# bundle.estimated_spent_by_paymaster

Constraints the SDK enforces before sending:

Constraint	Detail
Network	mainnet only; any other network raises
Size	one to five transactions
Order	`signatures` come back in bundle order
Cost	`estimatedSpentByPaymaster` is an estimate, not a settled charge

A returned bundleId means Jito accepted the bundle. The bundle may still be pending; acceptance is not confirmation or finality. Obtain each required application signature before sending the ordered bundle to the server.

your product wants gasless or paymaster-backed flows
your backend already owns the post-signing submission step
you want one server-owned path for ordered transaction submission

Check paymaster funding

TypeScript

const balance = await swig.paymaster.getBalance({ network: 'mainnet' });
// balance.configured, balance.address, balance.balanceLamports, balance.balanceSol

getIdpBalance() / get_idp_balance() reads the IdP paymaster instead of the API paymaster.

Transaction categories still matter

clientAuthorityTransactions / client_authority_transactions contain explicit embedded secp256r1 or secp256k1 signature requests
feePayerOnlyTransactions / fee_payer_only_transactions have no explicit signature requests, but may still require an Ed25519 transaction signature

Use the serialized transaction’s required signer set as the final authority before sending either category to a fee payer or sponsor.

Portal admin vs runtime usage

This page is about runtime submission. To create or manage a paymaster in the dashboard, use the portal docs:

Start Here

Wallet Access

Build Wallet Flows

Use Cases

Balances and Funding

Operate in Production

Workspace Admin

Submit and Sponsor Transactions

Retry safely with an idempotency key

Check paymaster funding

Transaction categories still matter

Portal admin vs runtime usage

​Sponsor one transaction

​Retry safely with an idempotency key

​Sponsor a bundle

​When sponsor submission fits

​Check paymaster funding

​Transaction categories still matter

​Portal admin vs runtime usage

Sponsor one transaction

Retry safely with an idempotency key

Sponsor a bundle

When sponsor submission fits

Check paymaster funding

Transaction categories still matter

Portal admin vs runtime usage