A price quote is not always a transaction payload

Ask what the response authorizes the application to do. A price can populate a comparison table. A route describes how funds might move. A transaction contains the call a wallet can submit. A signable order belongs to another execution path entirely.

Use a discriminated response model

A useful application model has separate variants such as indicative, needsBuild, transaction and order. Each variant exposes only the actions it supports. This is a proposed client design, not a standardized provider schema.

0x separates indicative price from firm quote. PancakeSwap distinguishes an agg route from a pcsx signable order. Both examples demonstrate why a single optional calldata field is an inadequate execution contract.

Handle missing payloads deliberately

Do not enable a wallet button merely because outputAmount exists. Require the fields for the selected variant, check their units and bind them to the input request. If a build call fails, preserve the displayed estimate with an explicit unavailable-execution state rather than fabricating a transaction from route details.

During an adapter migration, save response fixtures for every variant. A fixture containing an excellent price but no transaction should never reach sendTransaction. A new unknown execution type should stop at the adapter boundary until its lifecycle is implemented.