GuidesG3

Send a Slipstream request

Slipstream is a transaction submission side-channel on G3 chains. Where eth_sendRawTransaction returns a hash and leaves you polling for a receipt, Slipstream accepts a whole batch and returns an included, rejected, or retry verdict for each transaction.

The endpoint doesn’t queue transactions in a mempool, so your client must pace batches and handle retries. In return, you receive a synchronous verdict for every transaction instead of polling for receipts.

Slipstream is a permissioned endpoint that Conduit enables per chain. Contact your Conduit account team to turn it on for your G3 chain and to get the endpoint.

Send a batch

Call slipstream_sendRawTransactionBatch on your chain’s HTTP RPC endpoint. The single parameter is an array of hex-encoded, signed raw transactions, so params is an array containing that array.

$curl -s https://[YOUR_G3_RPC_URL] -X POST \
>-H 'Content-Type: application/json' \
>-d '{
>  "jsonrpc": "2.0",
>  "id": 1,
>  "method": "slipstream_sendRawTransactionBatch",
>  "params": [["0x02f8...a1", "0x02f8...b2", "0x02f8...c3"]]
>}'

Sign transactions exactly as you would for the public path: correct chain ID, nonce, and a maxFeePerGas at or over the current base fee.

Read the response

The result sorts your batch into three lists. Every transaction you submitted appears in exactly one of them.

1{
2  "jsonrpc": "2.0",
3  "id": 1,
4  "result": {
5    "included": [
6      {
7        "index": 0,
8        "hash": "0x9f2c...4e",
9        "sender": "0x1234567890abcdef1234567890abcdef12345678",
10        "nonce": 41,
11        "block_number": 75086,
12        "flashblock_index": 3
13      }
14    ],
15    "rejected": [
16      {
17        "index": 1,
18        "error": "nonce-too-low: state nonce 42"
19      }
20    ],
21    "retry": [
22      {
23        "index": 2,
24        "reason": "block-capacity: gas limit reached"
25      }
26    ]
27  }
28}

index is the zero-based position of the transaction in the array you sent. Match verdicts back to your transactions by index, never by list order. The three lists group transactions by verdict, not by submission order.

VerdictMeaningWhat to do
includedThe transaction ran and landed in a published flashblock.Advance. Treat it as a flashblock-level preconfirmation.
rejectedThe transaction wasn’t accepted in this attempt. The reason can be permanent or depend on current chain state.Inspect the reason and refresh chain state before you rebuild or retry the transaction.
retryThe transaction didn’t run, and you can retry it unchanged.Resend the same bytes.

An included verdict is a preconfirmation, not finality. The sequencer answers only after it publishes the flashblock carrying the transaction on the flashblocks stream, so an included verdict carries exactly the same trust level as the flashblock stream itself. It isn’t a canonical block, and it isn’t L1 finality.

The error and reason fields provide diagnostic text. Branch on the verdict list instead of parsing these messages as stable machine-readable values.

Limits and timeouts

The public RPC request body limit is 5 MiB. Hex encoding doubles the raw transaction size before JSON overhead, so keep the raw transaction total well below 2.5 MiB.

Set your HTTP timeout generously, around 10 seconds, to account for network, gateway, and routing time.

Use the provided public RPC endpoint for Slipstream requests.