Lifecycle Walkthrough

How a transfer moves through Connections, Conversions, and Settlements, the three modes, and the rules that govern retrying or resuming one.

Moving value creates a flow: one object representing one transfer attempt. Your backend creates it, your client advances it, and Dynamic settles it.

Step 1: Connections

Decide what the connection is for before making one.

Standalone. A wallet or an exchange account connects on its own. No flow is involved. Connect a wallet natively or through a hosted page to authenticate a user, or authorise an exchange account to read balances or send a direct withdrawal. Nothing here is quoted or settled, so none of the steps below apply.

As part of a flow. Paying, depositing, converting, or settling all move through a flow object. A wallet, an exchange account, or a deposit address funds it. Your backend creates the flow first; nothing attaches before that.

1. Create the flow. Your backend sets the mode, the amount, the settlement token and chain, and the destination. This is the only call your API token authenticates, so a browser client never holds an endpoint that accepts those fields. Everything after runs on a session token.
2. Attach the connection. A wallet the user connects, an exchange account they authorise, or a deposit address. Flow generates the deposit address as part of this step, not before. Attaching it declares where the value is coming from. It also mints the session token.

Step 2: Conversions

With a connection attached, Flow can price the transfer and request the funds. If it holds something other than what you settle in, this is where the conversion happens.

3. Get a quote. Dynamic returns the route, the fees, and an estimated time.
4. Prepare signing. The quote is locked in and a signing payload is returned.
5. Sign and broadcast. The payer’s wallet signs and submits to the network.
6. Report the transaction. Hand back the transaction hash so Dynamic can watch the chain.

A deposit address skips steps 4 to 6 entirely, because the payer sends funds externally rather than signing anything. A withdrawal is signed by your wallet rather than the end user’s.

Step 3: Settlements

7. Settle. Dynamic watches the chain and routes the funds to your destination, in the token and on the chain you configured. See Settlements.

Reaching source_confirmed does not mean the transfer is finished. Settlement can still be in progress: keep polling or processing webhooks until it reports completed or failed.

Modes and direction

One mode is chosen at creation and cannot change afterwards.

Mode	Amount set by	Source	Destination
Payment	You	The user’s wallet or exchange	Your treasury, vault, or merchant wallet
Deposit	The user	The user’s wallet or exchange	Your treasury, vault, or merchant wallet
Withdrawal	You	Your treasury, vault, or server wallet	The user’s wallet

The same steps also move value between your own wallets on different chains, for example wallet A on chain X to wallet B on chain Y: that’s a payment or deposit configured cross-chain, not a fourth mode.

Payments can also be created as a shareable payer URL instead of a flow you wire into your own UI, which suits invoices sent by email or chat.

Flow state and retries

A flow is a state machine: each action is valid only from certain states, and one called out of order is rejected. Before retrying a request or resuming an interrupted session, read the flow’s current state and act on that instead of replaying the last call. Cancel any time before broadcast; not after.

See Resume and retry by state for every state and what it allows next.

Next

Connections

What a payer can pay from, and which to offer.

Webhooks and events

How a flow reports its own progress.