POST /tx/batch — and why single-request submission matters

During benchmark testing, we hit a DNS resolution failure. Our test script fired 50 concurrent HTTP requests to testnet.asentum.com, and the local DNS resolver couldn't handle the burst. The chain was fine — the requests never left the client machine.

But it pointed to a real problem: every transaction submission is a separate HTTP request. One DNS lookup, one TLS handshake, one connection, one response. Multiply that by hundreds and you're spending more time on network overhead than on actual transaction processing.

The fix

New RPC endpoint: POST /tx/batch.

POST /tx/batch
{
  "transactions": [
    { "rawTx": "0x..." },
    { "rawTx": "0x..." },
    { "rawTx": "0x..." }
  ]
}

Response:

{
  "accepted": 3,
  "rejected": 0,
  "total": 3,
  "results": [
    { "accepted": true, "txHash": "0x..." },
    { "accepted": true, "txHash": "0x..." },
    { "accepted": true, "txHash": "0x..." }
  ]
}

One request. One connection. All transactions processed server-side in sequence and added to the mempool atomically. Per-transaction results so the caller knows which succeeded and which didn't.

Performance

In benchmark testing, the batch endpoint submitted 500 transactions in 3.3 seconds — 151 tx/s. The sequential approach (one request per tx) achieved 12.1 tx/s. That's a 12x improvement from a single HTTP endpoint change.

Use cases

Beyond benchmarking, batch submission is useful for:

• Airdrops and token distributions — send hundreds of transfers in one API call
• DEX order matching — submit a batch of matched trades atomically
• Migration scripts — deploy multiple contracts or seed initial state in bulk
• Indexers and relayers — forward accumulated transactions from a queue
• Load testing — push the chain to its limits without DNS/connection overhead

The existing POST /tx endpoint is unchanged. Single-transaction submission works exactly as before. The batch endpoint is purely additive.

What's next

The batch endpoint processes transactions sequentially on the server. A future optimisation could parallelise signature verification (the most expensive per-tx cost) while keeping state application sequential. But that's an optimisation — the endpoint is useful as-is.