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.valdium.xyz, 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 was 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 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, DEX order matching, migration scripts, indexers and relayers, and load testing — all without DNS and connection overhead per transaction.

The existing POST /tx endpoint is unchanged. The batch endpoint is purely additive. — dev team