PancakeSwap approval targets depend on the winning engine

Approval readiness belongs to a specific execution path. A wallet that has used PancakeSwap's aggregator route may still lack the permission required by a later X order.

PancakeSwap's integration notes distinguish an aggregator router approval from the Permit2 approval associated with the X signing domain. Read the winning candidate before checking permission.

Return an approval plan from the adapter

A proposed plan includes chain, token, owner, spender, required amount and mechanism. Keep this plan separate from transaction construction and from UI text. When the selected engine changes, replace the plan and invalidate the prior approval-read result.

Native input needs its documented funding path rather than an ERC-20 approval on a placeholder address. For token input, verify the actual spender through current deployment rules and read allowance for the real account.

Refresh after permission changes

If an approval transaction is required, wait for success and obtain a fresh candidate. The new winner may use another engine, so check its plan again. Avoid a loop that repeatedly asks for the old spender's approval while the new route requires a different one.

Present the permission being requested clearly. The user should be able to distinguish an on-chain token approval from the subsequent order signature or swap transaction.

Test alternating winners

A fixture can return agg first and pcsx after the approval delay. Assert that the application re-evaluates the target rather than assuming approvalComplete is a universal boolean. Reverse the order for a second fixture.

The same principle applies to cached state: key allowance by owner, token, spender and chain, not merely by the PancakeSwap brand. The brand identifies a product family; it is not an authorization address.