Contract call sequences
The protocol overview contains the short order sequence; this page contains the detailed sequences. See order lifecycle and priority bids for the flowcharts.
Solid arrows are calls or actions; dashed arrows are returns or delivered results. Each sequence groups related transactions; it is not one transaction from top to bottom. The app and wallet represent the user interface, not trusted settlement components. An indexer may observe emitted events for discovery, but neither an API nor an indexer is required by the contracts.
IncomingMatching and AsyncMatching are linked external libraries called in the hook's context. AsyncFiller, the price tree, and currency-settlement helpers operate on that same context; they are not independent custodians. Arrows from the matching library to PoolManager therefore execute as the hook. ERC-6909 claims and LP fee accounting live inside PoolManager. These sequences describe current source; deployed v1.3.0 contracts predate the incoming-memory path.
User order, book matching, and LP fallback
The LP fee and the LPs' half of the dynamic fee accrue through PoolManager's position accounting (the dynamic fee by donate); see dynamic-fee-ordering.md. Priority bids are not paid to LPs: every settled bid goes to the FeeVault. LPs do not receive an external callback on every fill.
Private fillers, continuation, repricing, and cancellation
These are alternative actions on open orders. Private fills and LP retries require the Router to remain authorized by the maker. Book continuation is permissionless and processes at most eight pairs per call.
To cancel several orders at once, the maker sends Router.multicall([cancelOrder(a), cancelOrder(b), ...]): each call above runs in turn as the maker, with its own unlock, and one failure reverts them all. A withdrawClaims call can follow in the same batch. Signed alternatives are Hook.updatePriceWithSig and Router.cancelWithSig; a relayer can submit the maker's signature. Signature checks precede the corresponding state change or cancellation unlock. Any uncaught revert rolls back the whole transaction, including transfers and bid settlements.
Pool setup, liquidity providers, and withdrawals
The liquidity manager below is a compatible Uniswap v4 periphery contract, not Async Swap's order Router. Its precise user-facing methods depend on the chosen periphery; the PoolManager calls shown are the common execution path. Setup and withdrawals are separate transactions from order execution.
Native and ERC-20 redemption require a positive amount, a nonzero recipient and a claim allowance; a failed delivery (ETH rejected, or a token refusing the recipient) reverts the redemption and restores the claims and allowance, and the holder can redeem to another recipient. Fee collection only redeems FeeVault's balances and is restricted to the current hook owner. It cannot redeem maker escrow.
Sources: Router, AsyncSwap, AsyncMatching, AsyncFiller, NativeClaims, TokenClaims, and FeeVault.