> ## Documentation Index
> Fetch the complete documentation index at: https://docs.nexroute.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Embedded mode

> Atomic backrun in the user's own transaction

In Embedded mode, the backrun runs in the same on-chain transaction as the user's swap. There is no separate backrun transaction. The user signs once (typically a Permit2 typed-data message), and a single transaction is broadcast that the chain executes atomically.

This is one of two integration modes for [Capture](/capture). For an alternative where you submit a fully signed transaction to a private endpoint and nexroute appends a separate backrun transaction behind it, see [RPC mode](/capture/rpc).

## How it differs from RPC mode

|                       | RPC mode                                                     | Embedded mode                                                    |
| --------------------- | ------------------------------------------------------------ | ---------------------------------------------------------------- |
| Who dispatches the tx | partner backend (via nexroute endpoint)                      | the user's wallet, or any dispatcher the partner doesn't control |
| User signatures       | one (full transaction)                                       | one (Permit2 typed-data)                                         |
| On-chain transactions | two (bundled)                                                | one                                                              |
| Backrun execution     | nexroute signs a separate backrun transaction bundled behind | inline call inside the user's transaction; no separate signature |
| Privacy               | guaranteed by nexroute relay                                 | depends on the dispatcher's RPC choice                           |

## How it works

1. The partner obtains aggregator swap calldata in their normal flow.
2. The partner asks nexroute for a backrun via the [backrun API](/capture/api-reference/eth_backrun); nexroute simulates how the swap will move the pool and returns calldata that arbitrages the resulting price.
3. The user signs a Permit2 typed-data message authorising the input token movement (token, amount, spender, deadline, nonce).
4. The resulting transaction is broadcast (typically by the user's wallet). The user's swap and the backrun execute atomically. If the backrun reverts, the user's swap still completes.

## Integration shapes

Embedded mode is a pattern, not a single integration. nexroute supports multiple shapes; pick the one that fits your stack.

<CardGroup cols={2}>
  <Card title="Wrapper contract" icon="cube" href="/capture/embedded/wrapper">
    Partner calls a nexroute-provided contract that handles Permit2 pull, aggregator forwarding, and atomic backrun in one entrypoint.
  </Card>

  <Card title="Calldata composition" icon="layer-group" href="/capture/embedded/composition">
    Partner receives backrun calldata and composes it into their own router, multicall, or post-hook.
  </Card>
</CardGroup>

Both shapes use the same [backrun API](/capture/api-reference/eth_backrun) and the same [trust model](/capture/embedded/security).

## When to choose Embedded mode

nexroute recommends [RPC mode](/capture/rpc) when feasible. Reasons:

* **Faster.** RPC mode is one round trip from partner to nexroute, after which nexroute dispatches the tx directly via private partnerships. Embedded mode adds a separate backrun API round trip before the user signs and relies on the dispatcher's broadcast path, which is typically slower than direct dispatch.
* **Cleaner separation of concerns.** The partner submits a raw signed transaction and nexroute owns the backrun end-to-end. Embedded mode pulls backrun integration into the partner's transaction construction.
* **Privacy by default.** RPC mode forwards via private partnerships; Embedded mode privacy depends on whoever broadcasts.

Embedded mode is the right choice when RPC mode isn't available. The decisive question is who dispatches the user transaction:

* **The user's wallet, or any party the partner doesn't control.** RPC mode requires the partner to relay the signed transaction through nexroute's private endpoint; if your integration ends with the user clicking submit in their wallet, that path isn't available. Embedded mode is the way.
* **The partner's own backend or a controlled dispatcher.** Use RPC mode.

If mempool exposure is a concern in Embedded mode, the dispatcher must use a private relay.

## Get started

<CardGroup cols={2}>
  <Card title="Wrapper contract" icon="cube" href="/capture/embedded/wrapper">
    Walkthrough for the wrapper-contract shape.
  </Card>

  <Card title="Calldata composition" icon="layer-group" href="/capture/embedded/composition">
    Walkthrough for the calldata-composition shape.
  </Card>

  <Card title="Backrun API" icon="code" href="/capture/api-reference/eth_backrun">
    Endpoint, request, response.
  </Card>

  <Card title="Security" icon="shield-check" href="/capture/embedded/security">
    Trust model and failure semantics.
  </Card>
</CardGroup>