Submit

When to use it, and when not to

Optional. A wallet that can broadcast its own transaction should just do that, and most integrations never need this endpoint. It exists for one case where the broadcast path changes the price the user actually gets.

A proprietary-AMM leg fills only when the market maker's price update is sequenced immediately before your swap in the same block, which is an ordering only a block builder can produce. Broadcast through the public mempool, the swap lands wherever the mempool puts it, the maker leg misses, and the router falls back to pools. Sending the same signed bytes here instead lets the builder do that sequencing.

Request

We never sign, never hold keys and never alter the bytes. The endpoint forwards only transactions that target our own router and call one of its swap entrypoints; anything else is refused before any upstream sees it, so it cannot be used as a general relay.

Response

path tells you which route the transaction took, and it is the only field worth branching on.

{
  "success": true,
  "data": {
    "txHash": "0x…",
    "path": "titan",
    "fallbackAfterSecs": 48
  }
}

The private window, and why it is bounded

A transaction sent privately is included only in blocks that builder wins. If it does not win one, the transaction sits signed, valid and invisible, which reads to a user as a hang. So after a fixed number of blocks without a receipt we re-broadcast the identical bytes to the public mempool.

Failures