Skip to content

Scam Detector Docs

Overview

The Scam Detector is an ideal source of threat intel for Web3 wallets and dashboard tools, as well as for security and compliance solutions serving a retail or institutional audience. Use the Scam Detector to build or supplement a blacklist, or as a transaction analysis tool by querying the Scam Detector at the point of approval or transaction to determine whether they are malicious.

The Scam Detector provides threat intelligence about malicious smart contracts, EOAs, and URLs engaging in scams and other end-user attacks. It relies on a bundle of underlying Forta bots, each monitoring for a specific threat type (ex: Ice Phishing).

The Scam Detector and its underlying bots are collectively maintained by the Forta community, including the Forta Foundation, Nethermind, and dozens of individual security researchers and developers.

How it works

Forta bots are monitoring on-chain activity 24/7/365. Some bots leverage a heuristic-based approach, others leverage machine learning to identify malicious activity. When bots identify an attack or scam on-chain, they create two types of threat intelligence:

Labels. A persistent tag placed on an entity (smart contract, EOA, URL) responsible for a scam or attack. Today, the Scam Detector assigns one label: “scammer” (additional labels, like "victim" and "stolen asset" may follow). The label will contain the following information:

  • label/entity - the address (either EOA or contract address) or URL
  • label/entityType - EntityType.ADDRESS or EntityType.Url
  • label/confidence - a confidence score from 0-1.0 with 1.0 being the most confident the label is correct
  • label/remove - a flag indicating whether the label is being added or removed
  • label/label - a string denoting the label that was placed on the entity. It currently is set to 'scammer'
  • label/metadata/bot_version - version of the bot when the label was added
  • label/metadata/threat_category - (see below)
  • label/metadata/address_type - EOA or contract (addresses only)
  • label/metadata/logic - (passthrough, ml, manual)
  • label/metadata/threat_description_url - URL that describes the threat_category in more detail

The Scam Detector currently monitors on-chain activity for the following threat categories:

  • sleep-minting - Fired when an alert combination is observed that points to a sleep minting attack
  • ice-phishing - Fired when an alert combination is observed that points to an ice phishing attack
  • wash-trading - Fired when an NFT wash trade has been observed
  • fraudulent-nft-order - Fired when an alert combination is observed that points to a fraudulent NFT order
  • native-ice-phishing-social-engineering - Fired when an alert combination is observed that points to an native ice phishing involving social engineering techniques (e.g. SecurityUpdate() function sig in the input data field)
  • native-ice-phishing - Fired when an alert combination is observed that points to a native ice phishing without a social engineering component
  • hard-rug-pull - Fired when a contract with hard rug pull techniques is identified
  • soft-rug-pull - Fired when a contract with soft rug pull techniques is identified
  • rake-token - Fired when a contract with a rake is identified
  • impersonating-token - Fired when a token contract has been identified that is impersonating a known established token (e.g. USDC or USDT)
  • address-poisoning - Fired when an alert combination is observed that points to address poisoning attack; this threat category is used for labeling poisoning addresses
  • address-poisoner - Fired when an alert combination is observed that points to address poisoning attack; this threat category is used for labeling poisoner addresses, aka the address that is initiating the poisoning and the contract performing the poisoning
  • attack-stages - Fired when an alert combination is observed that points to an attack on-chain that spans the 4 stages of an attack (funding, preparation, exploitation, and money laundering) Many of the alerts here point to rug pulls and rake tokens.
  • similar contract - Fired when a similar contract to a previously identified scammer contract has been identified
  • scammer association - Fired when an EOA is associated with a known scammer account (e.g. receiving or sending funds)
  • scammer-deployed-contract - When a known scammer deploys a contract

New threat types are regularly added to the Scam Detector by the Forta community.

Here’s a glossary defining threat types in more detail.

Using the Scam Detector

The Scam Detector labels are each available via Forta's GraphQL API. For accessing threat intel from the Scam Detector, we recommend querying labels generated by this bot (sourceIds parameter needs to be set to ["0x1d646c4045189991fdfd24a66b192a294158b839a6ec121d740474bdacb3ab23"].) The primary label is 'scammer'.

Labels

Labels allow a contributor to tag an entity (like an address) with a label. Labels are available via our GraphQL API. This API allows one to search by date range and page over results.

A recent one month sample of the labels can be downloaded here (prod, V1 label format) and here (beta, V2 label format).

Note:

To request entries that are currently accurate (and not later removed), pass state: true as part of the input. Otherwise, the response will contain point-in-time events (which may contain removal (remove:true) events).

At least one of: labels, sourceIds, or entities is required.

Example Query 

query Labels($input: LabelsInput) {
  labels(input: $input) {
    labels {
      label {
        label
        entity
        metadata
      }
      createdAt
    }
    pageInfo {
      endCursor {
        pageToken
      }
      hasNextPage
    }
  }
}

Example Input 

{
  "input": {
    "sourceIds": [
      "0x1d646c4045189991fdfd24a66b192a294158b839a6ec121d740474bdacb3ab23"
    ],
    "labels": [
      "scammer"
    ],
    "state": true,
    "first": 5,
    "metadata": {
      "chain_id": 56
    },
    "afterCreatedAtDate": "2023-04-03T15:01:33Z",
    "beforeCreatedAtDate": "2023-04-03T15:10:45Z",
    "after": {
      "pageToken": "29427820"
    }
  }
}

For a complete list of options, see the LabelsInput specification

Example Response 

{
 "data": {
   "labels": {
     "pageInfo": {
       "hasNextPage": true,
       "endCursor": {
         "pageToken": "21193"
       }
     },
     "labels": [
       {
          "createdAt": "2023-07-04T23:09:35.614989763Z",
          "id": "0x97555444ff87aa9a56431571c906c6ef7ab25a24165fed6b72969964d455dadb",
          "label": {
            "label": "scammer",
            "metadata": [
              "address_type=contract",
              "base_bot_alert_hashes=0x8f5e07151a1666d387a163bf91efdb346bc65c53c260e9e043125e762437ea84",
              "base_bot_alert_ids=SOFT-RUG-PULL-SUS-POOL-REMOVAL",
              "bot_version=2.15.3",
              "chain_id=1",
              "deployer_info=Deployer 0x02caf8b1e4b59529c9c100e8f0f90a3faeeeb2e4 involved in SCAM-DETECTOR-SOFT-RUG-PULL scam; this contract has been associated with this scam.",
              "feature_vector=",
              "label_version=2.1.0",
              "logic=passthrough",
              "model_name=v3_scammer_model.joblib",
              "threat_category=soft-rug-pull",
              "threat_description_url=https://forta.org/attacks#rug-pull"
            ],
            "remove": false,
            "entityType": "ADDRESS",
            "entity": "0x9bc388edeeb94c8017e0a6e178a8e7cb40f3d1f3",
            "confidence": 0.477
          },
          "source": {
            "chainId": 1,
            "alertId": "SCAM-DETECTOR-SOFT-RUG-PULL",
            "bot": {
              "id": "0x47c45816807d2eac30ba88745bf2778b61bc106bc76411b520a5289495c76db8"
            },
            "alertHash": "0x1b11901bfca2873e83a1cba50ee937a35279b873eff56214eaaefbe068c3582a"
          }
        }
     ]
   }
  }
}

Example as curl 

curl --request POST \
    --header 'content-type: application/json' \
    --url 'https://api.forta.network/graphql' \
    --data '{"query":"query Labels($input: LabelsInput) {\n  labels(input: $input) {\n    labels {\n      label {\n        label\n        entity\n        metadata\n      }\n      createdAt\n    }\n    pageInfo {\n      endCursor {\n        pageToken\n      }\n      hasNextPage\n    }\n  }\n}","variables":{"input":{"sourceIds":["0x1d646c4045189991fdfd24a66b192a294158b839a6ec121d740474bdacb3ab23"],"labels":["scammer"],"state":true,"first":5,"metadata":{"chain_id":56},"afterCreatedAtDate":"2023-04-03T15:01:33Z","beforeCreatedAtDate":"2023-04-03T15:10:45Z","after":{"pageToken":"29427820"}}}}'

More details on querying labels can be found in our Forta GraphQL API documentation.

Matching Threat Intelligence

Forta’s threat intelligence indicators consist of scammer contracts, EOAs, and Urls that can be matched against transaction data (either pre-signing, during transaction simulation, or after block building.)

Independent on the type of transaction data that will be used to match Forta's threat intelligence, specific matching logic need to be applied to obtain all relevant transactions based on the threat category observed as outlined below:

ice-phishing

Ice phishing involves a user issuing an approval, approvalForAll, increaseApproval or permit transaction. The to address is a benign token contract, but approval is granted to the scammer address specified in the input data of the transaction. As such, the input data or corresponding emitted events for approvals, approval for all and permit transactions need to be parse and the spender value ought to be matched against Forta’s threat intelligence.

fraudulent-nft-order

Fraudulent NFT orders are challenging to match against the Forta’s threat intelligence as the order is merely signed by a user, collected through web2 infrastructure (such as a web site) and then submitted by the scammer on the user’s behalf. The order itself does not include the scammer address.

However, the order gets executed by the scammer, so matching the from field will match those transactions. Once executed, the seaport protocol will transfer the digital assets to the scammer (which could be a different address from the invoking EOA) and matching emitted events for transfers would yield all relevant transactions.

address-poisoning

Address poisoning results in a user’s address history to be poisoned using token transfers or native asset dust. Matching should happen at two levels: 1. Match on any parsed transfer input data fields or corresponding event emissions for tokens. Note, either the to or the from could match the scammer. 2. Match on the from address for native assets transfers.

address-poisoner

Address poisoners are the initiator of the address poisoning activity. A simple matching of the from and to field (if a contract) would yield the relevant transactions.

native-ice-phishing/ native-ice-phishing-social-engineering

Native ice phishing are straight transfers of native assets to the scammer. Matching the to address of the transaction against Forta threat intelligence yield transactions for this type of scam.

hard-rug-pull/ soft-rug-pull/ token-impersonation/ rake-token

These threat categories are indicative of malicious token contracts that can be matched based on the transaction to address and/or log fields (e.g. transfer logs) post tx simulation.

wash-trading

Wash trading artificially inflates the value and trading volume of digital assets the user may hold. In order identify transactions associated with these wash traded digital assets, the scammer addresses need to be matched against to/ from/ input data fields/ and emitted events.

In addition, however, the actual wash traded digital asset is tainted and can be tracked by the transfer function. Note, given the contract could emit events with incorrect information - if created by the scammer; it is not a reliable data source.

sleep minting

Sleep minting is similar to wash trading in that the provenance of an NFT is no longer guaranteed. In order track the sleep minted token by the transfer function. Note, given the contract could emit events with incorrect information, which is prevalent in sleep minting attacks; it is not a reliable data source.

What chains are supported?

  • Ethereum
  • BNB Chain
  • Polygon
  • Avalanche
  • Arbitrum
  • Optimism
  • Fantom

The Forta community evaluates new chains on an ongoing basis.

False Positives

While the Scam Detector maintains high precision, it’s possible that it identifies a false positive. To address this risk, the Forta community manually verifies certain Scam Detector alerts within one business day. If a false positive is identified during the manual verification process, an FP alert will be emitted by the Scam Detector and the label will be removed. If you’re accessing the Labels API via the state endpoint, all labels are up to date and take into account the latest FP information.

Confidence Scores

The confidence score associated with a label is hard coded and based on the precision analysis performed by the Forta community or derived from the machine learning score. The hard coded score is updated on a monthly basis, and reflects the precision of the Scam Detector for a particular threat-category before manual verification.