# Fraud Prevention

Fuul includes multiple layers of protection to ensure that only legitimate users receive rewards, safeguarding your budget from sybil attacks, self-referrals, and other abuse.

## Sybil detection

A sybil attack occurs when someone creates multiple fake identities (wallets) to exploit your rewards system — claiming airdrops, manipulating staking rewards, or inflating referral counts with fake accounts.

Fuul uses machine learning and behavioral analysis to detect and prevent these attacks:

| Protection                       | How it works                                                                                                               |
| -------------------------------- | -------------------------------------------------------------------------------------------------------------------------- |
| **Behavioral cluster detection** | Detects wallets likely operated by the same user based on onchain behavior patterns                                        |
| **Self-referral detection**      | Detects when a referrer and end user share the same browser session (tracking ID), indicating the user referred themselves |
| **Bot activity detection**       | Analyzes frontend and onchain data to identify automated software                                                          |
| **Payout caps**                  | Limit the maximum rewards a single account can earn within a time window (e.g., monthly caps)                              |
| **Continuous monitoring**        | Real-time adaptation based on evolving patterns, with detailed reporting on flagged accounts                               |

### What happens when fraud is detected?

When fraud is detected:

* The **referrer payout is blocked** — the fraudulent referrer does not receive rewards
* The **end user still receives their payout** — legitimate user activity is not penalized
* The attribution is flagged and remains visible in the dashboard and attribution search results — it is not deleted

{% hint style="info" %}
Self-referral detection is **always enabled** for all projects. Other fraud detection features can be configured per project.
{% endhint %}

## Blacklist

Projects can maintain a blacklist of addresses that should be excluded from earning any rewards. When a blacklisted address triggers an event, the execution is automatically rejected — no attribution or payout is created.

| Feature                | Description                                                                                                      |
| ---------------------- | ---------------------------------------------------------------------------------------------------------------- |
| **Project-scoped**     | Each project manages its own blacklist. An address blacklisted by one project can still earn rewards in another. |
| **Immediate effect**   | Once an address is added, all subsequent trigger executions for that address are rejected                        |
| **Managed via webapp** | Add or remove addresses with optional labels for identification                                                  |

{% hint style="warning" %}
Removing an address from the blacklist does **not** retroactively approve previously rejected executions. Only future activity is affected.
{% endhint %}

## Wallet screening

Wallet screening checks whether a wallet address is allowed to receive payouts at the time rewards are distributed. This is a system-level compliance check separate from the project blacklist.

| Feature                          | Description                                                                                                                          |
| -------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------ |
| **Runs at payout distribution**  | Screening happens when a payout is about to be distributed                                                                           |
| **Blocked payouts are recorded** | Blocked wallets still have their payouts persisted for audit purposes                                                                |
| **Fail-open**                    | If screening encounters an error, the wallet is allowed through — preventing legitimate wallets from being blocked by service issues |

{% hint style="info" %}
Wallet screening is separate from the blacklist: the blacklist is managed by each project for their own needs, while wallet screening is a platform-level compliance mechanism.
{% endhint %}

## Viewing fraud activity

In the **Fraud Detection** tab of the dashboard, you can see everything Fuul detects and blocks:

* View transactions marked as pending and decide whether to approve or reject them
* See transactions that have been automatically declined
* Review flagged accounts and their activity patterns

{% embed url="<https://drive.google.com/file/d/1BaTlhH3Q6LX4-KC4ocjtRvFU1PM02Vsw/view?usp=sharing>" %}


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.fuul.xyz/core-concepts/fraud-prevention.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.