Submit blockchain transactions

post

https://api.mevx.io/api/v1/transaction

Submit signed blockchain transactions or build and submit transactions in a single request.
This endpoint supports two operation modes for maximum flexibility.

⚠️ ENCRYPTION REQUIRED

This endpoint requires AES-256-GCM encrypted request bodies.

All requests must be encrypted using your API credential's encryption key.
See the Request Encryption section in the Transactions tag description above for implementation details.

Request Headers:

Content-Type: text/plain
X-Encrypted: true

Response Headers:

X-Server-Signature: HMAC-SHA256 signature of response body (verify this!)

Operation Modes

Mode 1: Submit (Pre-signed transactions)

Submit one or more pre-signed transaction strings to the blockchain.
Use this mode when you've already signed transactions client-side.

Required fields: type: "submit" and signedTransaction array

Mode 2: Build and Submit

Automatically build, sign, and submit transactions based on provided parameters.
The API handles transaction construction, signing, and submission.

Required fields: type: "buildAndSubmit" and buildTransactionData object

Usage Notes

Transactions are submitted to the blockchain immediately
Returns transaction hash/signature upon successful submission
Failed transactions return detailed error messages
Use /transaction/status endpoint to track transaction confirmation
Multiple transactions in a batch are submitted sequentially
Each transaction submission consumes CU based on complexity

Accessibility

Tier Access: Starter, Pro, Enterprise

Compute Unit Cost: 10 CU per request

Chain Supported

Chain	Supported DEXs
Solana	Pump.fun, PumpAMM, Raydium (CLMM, CPMM, V4), Jupiter
Ethereum	Uniswap V2, Uniswap V3
Base	Uniswap V2, Uniswap V3
BSC	Fourmeme, PancakeSwap V2

Common Use Cases

Execute token swaps on decentralized exchanges
Automate trading strategies
Batch multiple transactions for efficiency
Implement programmatic trading bots
Execute arbitrage opportunities
Manage liquidity positions

Best Practices

Always encrypt requests - Unencrypted requests will be rejected
Verify response signatures - Check X-Server-Signature header
Always simulate transactions before submission when possible
Use appropriate slippage tolerance to avoid failed transactions
Set realistic gas/priority fees based on network conditions
Store transaction hashes for tracking and reconciliation
Implement retry logic with exponential backoff for network errors
Validate wallet balances before submitting transactions
Enable anti-MEV protection for large/sensitive transactions

Security Considerations

All requests must be encrypted with your encryption key
Verify all response signatures before processing
Consider using unsigned transaction mode for maximum security
Validate transaction parameters before submission
Monitor for unusual transaction patterns
Implement transaction amount limits
Use secure connections (HTTPS) for all requests

Recent Requests

Time	Status	User Agent
Retrieving recent requests…

Loading…

Body Params

chain

string

Blockchain network identifier. Determines which blockchain to submit the transaction to.
Common values: "sol", "eth", "bsc", "base"

requestId

string

length ≤ 128

The requestId from the /transaction/build response.
Required for Jupiter transactions — the Jupiter execute API needs this to match the order.

lastValidBlockHeight

string

Last valid block height from the /transaction/build response.
Required for Jupiter transactions — the transaction will be rejected by the network if submitted after this block height.

type

string

enum

required

Transaction submission mode:

submit: Submit one or more pre-signed transaction strings.

Use when you've already built and signed transactions
Requires signedTransactions field
Recommended for security-critical applications
For Jupiter: also requires requestId and lastValidBlockHeight from the /transaction/build response

buildAndSubmit: Build, sign, and submit in one request.

API handles transaction construction and signing
Requires buildTransactionData field
Convenient for rapid development and testing
Not supported for Jupiter exchange — Jupiter returns unsigned transactions that must be signed client-side

Allowed:

signedTransactions

array of strings

length between 1 and 10

Array of base64-encoded signed transaction strings.
Required when type is "submit".
Each string represents a fully signed, serialized blockchain transaction.

Important: Ensure transactions are properly signed with valid private keys.

signedTransactions

exchange

string

DEX protocol identifier for the swap.
Examples: "jupiter", "raydium", "pumpamm"

Important: This must match the exchange used when building the transaction. If you build with jupiter but submit with raydium, the transaction will be routed to the wrong backend and will not land on-chain.

setting

object

Transaction execution settings including anti-MEV protection.
Used with type: "submit" to configure how pre-signed transactions are submitted.

Note: Anti-MEV settings (antiMev, antiMevProvider, mevTip, mevPriorityFee) are ignored for Jupiter transactions. Jupiter handles transaction landing internally via its own infrastructure.

buildTransactionData

object

Transaction building parameters and configuration.
Required when type is "buildAndSubmit".
Contains all information needed to construct the transaction.

Responses

200Transaction submitted successfully to the blockchain

400Bad request - Invalid transaction parameters

401Unauthorized - missing, invalid, or expired API key

429Rate limit exceeded - too many requests

500Internal server error - unexpected system error