A familiar swap interface can still request an unfamiliar spender

A genuine aggregator domain can still serve a harmful request if its front end or dependencies are compromised. Past successful use and a saved bookmark do not prove the next approval matches the intended protocol.

Inspect the request boundary

Compare the input and output contracts, amount, recipient, chain and allowance spender in the wallet with your intended trade. The website’s own summary is not an independent check of data it generated.

0x’s contract documentation shows why contract roles matter: execution entry points and allowance targets can differ. An unexpected address should be verified by role, not accepted because it appears in a swap-related request.

Use independent evidence

Consult official deployment documentation through a known source, check credible incident notices and use supported device review. Clear signing can help expose meaningful fields on the signer, where supported.

A wallet security warning or newly requested broad allowance deserves attention even if the application looked normal yesterday.

If you already interacted

Record the time, domain, transaction hash and signed permission. Check whether the suspicious request was rejected, remained pending or confirmed. The response depends on what was authorized and whether secrets were exposed.

A front-end incident does not automatically mean every underlying contract is compromised. Conversely, a team restoring its website does not automatically revoke permissions granted during the incident. Follow exact affected-contract guidance and verify your own account’s state.