False positive: defade.org "Request blocked — this dApp could be malicious"

[DeFadeLtd]

Summary

Our domain defade.org (and API subdomain api.defade.org) is being flagged by Phantom's
request scanning: when users submit a transaction or signing request, Phantom shows
"Request blocked - This dApp could be malicious. For your safety, Phantom has blocked
this request." We believe this is a false positive.

DeFade is a token risk-analysis platform for Solana and EVM chains (rug-risk scoring,
bundle detection, holder analysis), live at https://defade.org with a paid Pro tier,
iOS/Android apps, and a public MCP connector. GitHub: https://github.com/DeFadeLtd

We've verified defade.org does NOT appear in the public blocklist repo
(github.com/phantom/blocklist), so this appears to come from the transaction-scanning
layer, not a domain listing.

Likely trigger: we recently launched "Protected Trade", an integration with Definitive's
Flash API (https://flash.definitive.fi, by https://definitive.fi) for MEV-protected
execution. The documented integrator flow involves (a) an SPL token delegate approval to
Definitive's settlement program and (b) gasless Ed25519 message signing of order
payloads. This pattern can superficially resemble drainer behavior to automated
heuristics, but it is the standard flow for every Definitive Flash integrator
(https://flash.definitive.fi/docs). The flag also hits plain SPL transactions our page
builds itself (e.g. a wSOL closeAccount unwrap), so it appears to apply to the origin
rather than any specific transaction.

Could you please review defade.org and remove the flag? Happy to provide anything that
helps verification - company details, integration source, or a walkthrough of the
signing flow.

Example

https://defade.org

Steps to Reproduce

The flagging is intermittent - some requests from our origin trigger the block and
others go through, which is why we believe this is per-request heuristic scoring
rather than a deliberate listing:

• Yesterday (Aug 31 - Sep 1 UTC): several small market buys through our Definitive
  Flash integration triggered "Request blocked - This dApp could be malicious" on the
  transaction/signing prompts. Proceeding via "Proceed anyway (unsafe)" worked.
• Today (Sep 2 UTC): the same buy and sell flows went through with NO warning, but a
  plain wSOL unwrap (a closeAccount transaction built by our page, no external
  program) was blocked with the same warning.

To attempt reproduction:

1. Open https://defade.org with Phantom installed, scan any Solana token, open the
   "Protected Trade" modal, and connect Phantom.
2. Run a small buy, or press "Unwrap to SOL" when the wallet holds wSOL.
3. Some of these requests show "Request blocked - This dApp could be malicious. For
   your safety, Phantom has blocked this request." (screenshot attached); others are
   allowed. We have not found a pattern that reliably triggers or avoids it.

The concern: users who hit the warning on their first trade see our dApp labeled
malicious, and unlike us they won't retry.
Screenshot below:

Phantom Version

26.27.0

Is there an existing discussion for this?

• I have searched the existing discussions

[mmirabi]

Hey, sorry you’re dealing with this — these intermittent false positives from the transaction-scanning layer are pretty frustrating, especially when the domain isn’t even on the public blocklist.
From Phantom’s own developer docs, this exact warning usually comes from the simulation / heuristic layer (not the static blocklist). The recommended path is:

Go through the official Domain and Transaction Warnings guide:
https://docs.phantom.com/developer-powertools/domain-and-transaction-warnings
Submit a review request through the form linked in that page (or email the review team if the form points you there). Include the same details you already posted here — the Definitive Flash integration, the fact that even plain closeAccount / wSOL unwrap is getting hit, and the intermittent nature.

A few other people in similar situations (new domains + non-standard signing patterns like gasless/Ed25519 or delegate approvals) got it cleared after following that process. Sometimes it also helps to make sure you’re using signTransaction first when there are multiple signers, and that transactions simulate cleanly with sigVerify: false beforehand.
Hope they clear it quickly for you.
Good luck!

[DeFadeLtd]

Thanks, appreciate the pointers! We've gone through the Domain and Transaction
Warnings guide and submitted the dApp Review form, referencing this discussion
and a Solscan link to one of the affected transactions.

On the technical side: the intermittent warnings turned out to correlate exactly
with transactions that would have failed simulation - a pre-built sponsored
transaction whose blockhash had expired while setup confirmed, and a wSOL
closeAccount fired at an already-empty account from a stale balance read. We've
since shipped fixes so our origin no longer produces failed-simulation
transactions (fresh quotes after setup lands, live balance checks before
building the unwrap), and we're looking at pre-simulating with sigVerify: false
as an extra guard. Our multi-signer case already uses signTransaction.

Hoping the review clears the flag - will report back here for anyone hitting
the same thing with gasless/delegate-approval integrations.

[DeFadeLtd]

Update: resolved. Phantom support confirmed this was a "new domain" warning and cleared it verified on our side, no warnings on subsequent transactions. For anyone else hitting this with gasless/delegate-approval flows: the review form linked from docs.phantom.com/developer-powertools/domain-and-transaction-warnings is the right channel, and make sure your own transactions can't fail simulation (fresh blockhashes, no doomed instructions) - those failures feed the heuristic.

[Th3Ya0vi]

Please follow our domain and transaction warnings guide, including the linked review form if you need further assistance. Thanks!