Smart contract wallets need signature compatibility checks

An integration that recovers an externally owned address from every signature does not automatically support smart contract wallets. Contract accounts can apply their own authorization rules.

ERC-1271 specifies isValidSignature for contract-based validation and a defined success return value. Its result can depend on contract state, authorized owners and other context. A signature that was valid earlier need not remain valid after the wallet's configuration changes.

Check the whole path

Support requires more than the browser wallet's ability to display typed data. The API, signed-order protocol and settlement verifier must support the contract account's signature format and validation. An adapter should advertise this capability explicitly and block an unsupported path before the user spends time signing.

Transaction-based swaps have their own requirements. The sender executing the call may be the smart account rather than its human owner's externally owned address. Quote, allowance and simulation must use the account that actually owns and spends the tokens.

Avoid an unsafe fallback

If contract-signature validation fails, do not silently change the order's owner to one signer or route funds through a different address. Offer a documented compatible execution path, or explain that the selected account is unsupported for that mode.

Maintain fixtures for a valid contract signature, an invalid return value, a reverted validation call and a wallet whose authorized signer changes after quoting. Keep these separate from ordinary EOA signature fixtures.

For systems supporting counterfactual or delegated accounts, account classification may require additional standards and provider support. A simple eth_getCode check should not become a universal compatibility promise. Record the exact wallet and execution modes your integration has verified, and treat unknown capabilities conservatively.