After The Swap

A successful swap emits events carrying the exact amounts moved. Reconcile against those rather than against your quote — the quote was a prediction, the events are what happened.

Confirm it settled

Check the transaction receipt's status. A status of 0 means the swap reverted and nothing moved — no partial fill, no tokens taken. Retry after re-reading the free checks on Check eligibility and taking a fresh quote.

A successful receipt is the only confirmation you need. Do not infer settlement from a successful quote — quoteNet answers whether the arithmetic works, not whether a swap happened.

The events to reconcile against

SwapExecutedExtended — the one to use

event SwapExecutedExtended(
    address indexed trader,
    address indexed fromToken,
    address indexed toToken,
    address destination,
    uint256 fromAmount,
    uint256 toAmount,
    uint256 normalizedAmount,
    bool isMaker
);

fromAmount and toAmount are in each token's own decimals — these are the two figures to book. normalizedAmount is scaled to 18 decimals regardless of the tokens involved, so do not mistake it for a native amount: a 0.99 USDC input appears as 990000 in fromAmount and 990000000000000000 in normalizedAmount.

isMaker is pool bookkeeping — either value is normal, and it does not affect what you received.

SwapExecuted carries only normalizedAmount — the input scaled to 18 decimals — and no output amount, so it can tell you neither what you received nor what you sent in native units. Use SwapExecutedExtended, which carries both fromAmount and toAmount in each token's own decimals.

SwapFeeApplied — only when a fee applies

event SwapFeeApplied(
    address indexed client,
    address indexed fromToken,
    address indexed toToken,
    uint256 grossOut,
    uint256 fee,
    uint256 netOut
);

This is the fee breakdown, and it shows where the fee comes from: grossOut - fee = netOut. The fee is deducted from the output, not added to your input — so you never need to send extra to cover it.

This event does not fire when the fee is zero. Whether a fee applies depends on the input token and your contract, not on the direction — so you cannot predict from the direction alone whether this event will appear. Treat its absence as "no fee," not as an error.

Do not build reconciliation on this event. Because it is silent at zero, anything that learns about fees by watching it cannot tell "the fee was zero" from "no swap happened". The settled amounts are recorded regardless — reconcile from those.

Others you may see

Alongside the two above you will see ordinary ERC-20 Transfer events for both tokens, and Approval events from the approve-and-spend pattern. The pool emits some events of its own for internal bookkeeping; they carry nothing about your swap, so you can ignore anything not described on this page.

Where the output arrived

For iBENJI → stablecoin, the output is at your calling contract — the destination rule guarantees it. For stablecoin → iBENJI, it is at whatever destination you named.

If your contract will ever need to move the output elsewhere, build that capability in before you deploy. A contract with no way to transfer tokens out will hold them indefinitely, and the function cannot be added later unless the contract is upgradeable. Holding the output is a perfectly valid design — it is just worth deciding deliberately either way.

Reconciling

For each swap, record:

• the transaction hash and block number — the pool's fees and reserve change over time, so a result without a block number cannot be reproduced later
• fromAmount and toAmount from SwapExecutedExtended
• fee from SwapFeeApplied, or zero if it did not fire
• the destination that actually received the output

Compare toAmount against the net you passed as minAmountOut. It should be greater than or equal to it — the swap would have reverted otherwise.

Before the next swap

Take a fresh quote. Both inputs to a quote move without notice: the pool owner can change fees with immediate effect, and the reserve is shared with other participants. A quote from earlier in the same block sequence may no longer hold.

If you approved the pool for exactly the amount you swapped, your allowance is now back to zero and the next swap approves again. If you granted an unlimited approval instead, it is still outstanding — see Execute a swap for why per-swap approval is preferred.