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

# Settlements

> Choose the token and chain you receive, the strategy used to get there, and where the funds land.

Settlement is the half of a flow you control. The payer chooses what they send; you declare what you want to receive, and the flow reconciles the two.

## Settlement currencies

You nominate the token and chain you want to be paid in. If the payer sends something else, the flow [converts](/docs/flow/conversions) on the way. You receive what you configured, regardless of what arrived.

More than one settlement can be configured on a flow. Each needs a matching destination on the same chain, so a flow that accepts USDC on two chains needs somewhere for each to land.

## Routing strategy

When several routes could satisfy a settlement, a strategy decides which one is used:

| Strategy            | What it optimises for                                               |
| ------------------- | ------------------------------------------------------------------- |
| **Cheapest**        | Lowest total cost, counting gas and fees                            |
| **Fastest**         | Fewest steps                                                        |
| **Preferred order** | The first available quote, in the order your settlements are listed |

Preferred order is the one to reach for when you have a genuine preference between tokens or chains rather than a preference about cost or speed.

## Source chains

A payer can pay from EVM, Solana, Sui, Bitcoin, or TRON. That is independent of what you settle in, so a payer holding an asset on one chain can pay a merchant settling on another without bridging anything themselves.

## Destinations

Funds settle to an address you provide. That can be a Fireblocks vault, a Dynamic embedded wallet, or any other address you control.

Each destination is matched to a settlement by chain. For a withdrawal, the destination is the end user's wallet and is supplied per flow, which is how a shared treasury pays out to many different users.

## Cross-chain orchestration

Cross-chain settlement orchestration is on by default. Turning it off keeps a flow on a single chain, which is worth doing when you have no intention of accepting cross-chain payments and would rather a mismatched source failed than be routed.

## Memos and reconciliation

Any flow can carry a memo, which is the mechanism for tying a payment back to something in your own system: an order ID, a user account, an invoice number. A memo persists through the whole lifecycle and appears in every webhook payload.

Memos also satisfy chain-level requirements. Networks such as Cosmos need a memo or tag to route funds correctly, so the field does double duty.

For reconciliation, pair the memo with the settlement transaction hash reported when settlement completes. See [Webhooks and events](/docs/flow/webhooks).

## Next

<Columns cols={2}>
  <Card title="Compliance" href="/docs/flow/compliance">
    The checks that run before funds move.
  </Card>

  <Card title="Webhooks and events" href="/docs/flow/webhooks">
    Knowing when settlement finished, and reconciling it.
  </Card>
</Columns>