# Alerts History
Source: https://docs.extractor.live/a3-documentation/alerts-history

Browse, filter, and resolve every alert fired across your portfolio in the Alerts History — a paginated log of detector and trigger events.

<img alt="Alerts History table with severity badges, project names, categories, score changes, and right-hand filter panel" />

## Overview

Navigate to **Alerts History** in the left sidebar to access the full alert log. The table shows up to 10,000 items and paginates at 100 per page by default (adjustable). Click **Refresh** to reload the latest data.

## Alert Table

Each row contains:

| Column | Description |
| - | - |
| **Severity** | `INFO`, `LOW`, `MEDIUM`, `HIGH`, or `CRITICAL` — color-coded badge |
| **Project** | The project that generated the alert, with its logo |
| **Category** | The risk or compliance category that triggered the alert (category names vary by org) |
| **Score Change** | The score before and after the alert, e.g. `85.00 → 0.00` |
| **Date** | Timestamp of the alert |

Click any row to open the **Alert Details** panel.

## Alert Details

The slide-over panel shows the full context of a single alert:

* **Alert name** — descriptive name of the rule that fired (e.g. `AAVE TVL (<45.5B), 10%`)
* **Context value** — human-readable metric snapshot (e.g. `TVL: $19.68B / $10.29B / $9.38B`, or a transaction hash)
* **Date and time** — exact timestamp
* **Severity** — badge label
* **Score Change** — before → after values
* **Alert status** — `UNRESOLVED` (orange) or `RESOLVED` (green)
* **Raw data** — key/value pairs of the underlying on-chain data that triggered the rule

Two action buttons appear at the bottom:

| Button | Effect |
| - | - |
| **Mark as Resolved** | Marks the alert resolved; moves it to the Resolved filter view |
| **Report a Mistake** | Flags the alert as a potential false positive for review |

Use **Previous** / **Next** in the panel header to step through adjacent alerts without closing the panel.

For full details on resolving alerts — individually, in bulk, and from other pages — see [Resolving Alerts](/a3-documentation/resolving-alerts).

## Filters

The right-hand sidebar applies filters instantly to the table.

### Alert Status

Toggle between **Resolved** and **Unresolved** alerts.

### Severity

Filter by severity level: Low, Medium, High, or Critical.

### Project Name

Search box and checkbox list to filter by one or more projects.

### Category

Filter by risk or compliance category. The available categories match those configured for your organization. Common examples:

* Web3 Security · AML/CFT · Financial Anomaly · Operational Security · Sentiment · Governance *(standard DeFi)*
* Security · Compliance · Financial · Policy *(regulatory monitoring)*
* Per-asset categories (ETH, BTC, SOL, etc.) *(asset monitoring orgs)*

### Date

Predefined ranges or a custom date picker:

* Today · 1 week · 1 month · 6 months · 1 year · All time · Custom date range


# Analytics
Source: https://docs.extractor.live/a3-documentation/analytics

Build custom Analytics dashboards in Hacken Extractor with widgets that visualize on-chain risk, alerts, and detector data over time.

## Overview

The Analytics section lives under **Analytics** in the left sidebar. It expands to list all dashboards in your organization. Click any dashboard name to open it, or click **+ Add Dashboard** to create a new one.

## Dashboard Controls

When a dashboard is open, the following controls appear in the header:

| Control | Description |
| - | - |
| **Resize** toggle | Enables drag-to-resize mode for widgets on the canvas |
| **Save** | Saves the current layout and widget configuration |
| **Refresh** | Reloads all widget data from the latest on-chain state |
| **Add Widget** | Opens the widget picker to add a new chart or data block |
| **Properties** | Opens dashboard-level settings (name, description, etc.) |
| **Delete** | Permanently deletes the dashboard |

## Widgets

Each dashboard is composed of widgets. Widgets are independent charts or data panels that you configure and position freely on the canvas.

Widget types include time-series charts (e.g. Raingraph), which can visualize metrics like protocol TVL share, token volumes, or risk scores across multiple data sources simultaneously.

Each widget has its own title and subtitle. The Raingraph type, for example, renders a stacked area chart — useful for comparing the relative share of multiple protocols over time.

## Working with Dashboards

<Steps>
  <Step title="Create a dashboard">
    Click **+ Add Dashboard** in the Analytics menu. Give it a name and confirm.
  </Step>

  <Step title="Add a widget">
    Click **Add Widget** in the dashboard header. Select a chart type, configure the data source and parameters, then click Save.
  </Step>

  <Step title="Resize and rearrange">
    Enable **Resize** mode, then drag widget edges to resize or drag widget headers to reposition.
  </Step>

  <Step title="Save your layout">
    Click **Save** to persist the layout. Unsaved changes are lost on navigation.
  </Step>
</Steps>


# Audit Trail
Source: https://docs.extractor.live/a3-documentation/audit-trail

Review every user action in your Hacken Extractor organization with the Audit Trail — a tamper-evident log of logins, changes, and configuration updates.

<img alt="Audit Trail page showing the log table with Entity, User, Date and time, Id, and Action columns, plus filter controls at the top" />

## Overview

Navigate to **Audit Trail** in the left sidebar. The trail records all significant user actions — logins, configuration updates, and more — with full attribution and timestamps.

Click **Refresh** to reload the latest entries. Toggle **UTC Timezone** in the top-right to display timestamps in UTC or your local timezone.

## Log Table

Each row in the audit log contains:

| Column | Description |
| - | - |
| **Entity** | The type of object that was acted upon (e.g. `User`, `Project`, `Contract`) |
| **User** | Email address of the user who performed the action |
| **Date and time** | Exact timestamp of the action |
| **Id** | Internal identifier of the affected entity |
| **Action** | Action type — e.g. `LOGIN`, `UPDATE`, `CREATE`, `DELETE` |
| **Details** | Link to open a full detail view of the action |

## Filters

Use the filter bar at the top to narrow results:

* **Search** — free-text search across entity names and user emails
* **Entity** — dropdown to filter by entity type
* **Action** — dropdown to filter by action type
* **Date range** — date pickers to select a start and end date (defaults to the last 30 days)

## Common Action Types

| Action | Meaning |
| - | - |
| `LOGIN` | A user signed in to the platform |
| `UPDATE` | A configuration, setting, or project property was changed |
| `CREATE` | A new resource was created |
| `DELETE` | A resource was removed |

<Note>
  The Audit Trail is read-only. Entries cannot be edited or deleted, ensuring an unmodifiable compliance record.
</Note>


# Dashboard
Source: https://docs.extractor.live/a3-documentation/dashboard

The Dashboard is the main landing page after login — it shows a portfolio-wide risk or compliance summary, latest alerts, and per-category score trends.

<img alt="Dashboard overview showing the Average Compliance Scoring section with radar chart, score timeline, and per-category breakdown" />

## Overview

The Dashboard aggregates scoring data from all projects in the currently selected portfolio. It refreshes automatically; the last refresh time is shown in the header (`Last update: DD MMM YYYY / HH:MM:SS`).

<Note>
  The Dashboard's labels and categories are configured per organization. You may see **"Average Risk Scoring"** or **"Average Compliance Scoring"** depending on your setup. Category names and the two quick-stat labels also vary by organization.
</Note>

## Quick Stats

Two summary numbers appear at the top-right of the Latest Alerts card:

| Stat | Description |
| - | - |
| **Active** / **Licensed** | Projects with active monitoring enabled (label varies by org) |
| **Monitored** | Total number of projects in the current portfolio |

## Latest Alerts

The Latest Alerts card lists the four most recent alerts across all projects. Each entry shows:

* **Severity badge** — `INFO`, `LOW`, `MEDIUM`, `HIGH`, or `CRITICAL`
* **Project name** — the originating project
* **Context value** — a human-readable metric snapshot (e.g. TVL values, transaction details, a price change)
* **Timestamp** — date and time the alert fired

Click the expand icon (↗) in the card header to open the full [Alerts History](/a3-documentation/alerts-history) view.

## Scoring Section

This section gives a portfolio-level snapshot across all configured categories. Use the time-range selector (`1D / 1W / 1M / 6M / 1Y / All Time`) to control the period shown.

### Risk / Compliance Parameters Chart

A radar chart (hexagonal or multi-axis polygon) plots the current score (0–100) for each configured category. Each axis represents one category. The shape of the polygon indicates overall health — a full outer polygon means all categories score 100.

Scores are color-coded:

* **Green** — healthy (near 100)
* **Orange / Yellow** — moderate risk
* **Red** — elevated risk (near 0)

The number of axes and their names depend entirely on your organization's configuration. Examples:

| Configuration type | Sample axes |
| - | - |
| Standard DeFi risk | AML/CFT · Financial Anomaly · Governance · Operational Security · Sentiment · Web3 Security |
| Regulatory compliance | AML/CFT · Tokenomics · Attack detection · Audit Relevancy · Development · Governance |
| Per-asset monitoring | BTC · ETH · SOL · USDT · stETH · LINK · Security · Compliance · Financial · Policy |

### Average Score Chart

A time-series line chart shows how the composite average score has changed over the selected period. The current score and its delta are shown in the top-right corner (e.g. `▼ 2.50   64.33`).

### Per-Category Breakdown

Below the charts, each category is listed as a row containing:

* **Icon and name**
* **Alert count** — e.g. `452 new alerts` or `no changes`
* **Current score** — e.g. `42.00`
* **Score delta** — change badge (red = score dropped)
* **Trend sparkline** — mini chart showing score history
* **Percentage bar** — score on a 0–100% scale


# Introduction
Source: https://docs.extractor.live/a3-documentation/intro

A3 is a Regulatory Compliance Intelligence Platform — a single source of truth for compliance, security, and economic risks across the Web3 ecosystem.

## What is A3?

A3 is a real-time compliance and risk monitoring platform built for Web3 organizations. It continuously scores your projects across configurable risk dimensions and alerts you the moment a threshold is breached.

Every A3 workspace is tailored to its client's regulatory context — the scoring categories, portfolio structure, compliance frameworks, and terminology all adapt to match the organization's specific requirements.

<CardGroup>
  <Card title="Dashboard" icon="gauge" href="/a3-documentation/dashboard">
    Live risk scores, latest alerts, and a portfolio-wide summary at a glance.
  </Card>

  <Card title="Portfolios & Projects" icon="folder-open" href="/a3-documentation/portfolios-and-projects">
    Organize monitored protocols and assets into groups, and drill into individual project details.
  </Card>

  <Card title="Alerts History" icon="bell" href="/a3-documentation/alerts-history">
    Full searchable log of every alert with severity, category, and resolution status.
  </Card>

  <Card title="Analytics" icon="chart-line" href="/a3-documentation/analytics">
    Custom dashboards with widgets for deep on-chain data analysis.
  </Card>

  <Card title="Audit Trail" icon="clock-rotate-left" href="/a3-documentation/audit-trail">
    Tamper-evident log of all user actions within your organization.
  </Card>

  <Card title="Settings" icon="gear" href="/a3-documentation/settings">
    Profile preferences, two-factor authentication, and team management.
  </Card>
</CardGroup>

## Customization by Organization

A3 is highly configurable. The following aspects adapt to each client's setup:

| Element | Examples seen in practice |
| - | - |
| **Top-level group label** | Portfolios, Policies, Licenses |
| **Risk / compliance categories** | Standard DeFi (AML/CFT, Web3 Security…), per-asset (ETH, BTC, SOL…), regulatory (Tokenomics, Audit Relevancy, Attack detection…) |

## Default Risk Categories

A3 evaluates every project across six dimensions by default:

| Category | What it measures |
| - | - |
| **Tokenomics** | Token supply health, issuance events, allocation integrity |
| **Audit Relevancy** | Audit coverage, relevancy, and freshness of security assessments |
| **AML / CFT** | Anti-money laundering and counter-financing-of-terrorism signals |
| **Attack detection** | Exploit patterns, attack vectors, and on-chain threat signals |
| **Development** | Code activity, smart contract update patterns, and development health |
| **Governance** | On-chain governance participation and voting health |

Categories are fully configurable per organization. Some setups use per-asset axes (ETH, BTC, SOL…) or different risk dimensions instead. Scores always run from **0** (critical risk) to **100** (clean).


# Portfolios & Projects
Source: https://docs.extractor.live/a3-documentation/portfolios-and-projects

The top-level grouping organizes related projects for collective monitoring. Each project represents a monitored protocol, asset, exchange, or entity.

<img alt="Project Overview tab showing Compliance Live Scoring radar chart, per-category alert counts, and License Status panel" />

## Top-Level Groups

The left sidebar shows your organization's top-level groups — the label and structure depend on your A3 configuration:

| What you might see | Typical use case |
| - | - |
| **Portfolios** | DeFi protocol monitoring |
| **Policies** | Regulatory policy and asset monitoring |
| **Licenses** | License-based compliance frameworks |

Click the **`>`** button next to the group label to open the picker, which lists all groups in your organization with their project counts.

Selecting a group scopes the Dashboard and all other views to that group's data.

## Projects

Within a group, click **`>`** next to **Projects** to open the project list. Each row shows:

| Column | Description |
| - | - |
| **Name** | Project name with logo |
| **Status** | `Active` (monitoring running) or `Pending` (setup incomplete) |
| **Alerts** | Alert counts by severity: critical (red), warning (orange), info (blue), plus unread count |
| **Score** | Current composite score (0–100) with a color-coded dot |

Projects can represent DeFi protocols (Aave, AsterDEX), specific assets (Bitcoin, Ethereum, Tether), centralized exchanges (Binance, Coinbase, ByBit), or any other monitored entity.

## Project Detail

Project detail tabs are configurable per organization. The tabs shown below are the default set — your A3 workspace may have a different selection, different tab names, or additional custom tabs depending on what your organization has enabled.

<Tabs>
  <Tab title="Overview">
    The Overview tab shows a project-level scoring snapshot and compliance status.

    **Risk Live Scoring / Compliance Live Scoring**

    A radar chart plots current scores across all configured categories for this project, alongside a list of categories showing alert counts or a pass (✓) indicator. The section is labelled **"Risk Live Scoring"** in risk-focused organizations and **"Compliance Live Scoring"** in compliance-focused ones.

    The number of axes on the chart matches the categories enabled for the organization. Organizations with per-asset monitoring may have many axes (e.g. one per tracked asset: ETH, BTC, SOL, LINK, USDT…).

    **Alerts**

    The Alerts section shows a tabbed feed of alerts for this project:

    * **All** — every alert across all categories, with the total count shown on the tab
    * **One tab per category** — alerts filtered to that specific category (e.g. Financial Anomaly, Sentiment, Web3 Security), each showing its own count

    Selecting a category tab filters the list to only alerts belonging to that category. The categories shown match those configured for your organization.

    The named compliance framework variant appears alongside the status dropdown and shows individual requirement items — for example:

    | Item | Possible statuses |
    | - | - |
    | Custom | Passed ✓, Failed ✗, Pending, Custom (or any free text) |
    | Security | Passed ✓, Failed ✗, Pending, Custom |
    | Governance | Passed ✓, Failed ✗, Pending, Custom |
    | Tokenomics | Passed ✓, Failed ✗, Pending, Custom |
    | Documentation | Passed ✓, Failed ✗, Pending, Custom (or free text) |

    The checklist items themselves are configurable per organization — your A3 workspace may have a different set of requirement names under the compliance framework panel.

    **About**

    A short description of the project and a link to its official website. Editable via the pencil icon. Some organizations also display a **Legal Name** field (the registered legal entity name of the project).
  </Tab>

  <Tab title="Monitoring">
    <img alt="Monitoring tab showing summary stats and the Smart Contracts table with contract names, auditor status, monitoring toggles, and per-severity alert counts" />

    The Monitoring tab shows the full picture of what is being watched for this project.

    **Summary stats:**

    | Stat | Description |
    | - | - |
    | Monitored Smart Contracts | Active / total smart contracts under monitoring |
    | Monitored Wallets | Active / total wallets under monitoring |
    | Total Alerts | Cumulative alert count |
    | Unread Alerts | Alerts not yet reviewed |

    **Smart Contracts table** lists every tracked contract with:

    * **Contract Name** and network (e.g. BSC, Ethereum, Mainnet, or N/A)
    * **Auditor** — audit firm name and relevancy date, or `Not Audited`
    * **Monitoring** — enabled / disabled
    * **AML/CFT Monitoring** — enabled / disabled
    * **Alerts** — per-severity alert counts for that contract

    Each row has two action controls on the right:

    * **✏ Edit** — opens a modal to manage the contract's audit records (auditor name, audit status, audited date, expiry date) and tokenomics allocation addresses. Audit entries can be added, edited, or deleted individually.
    * **˅ Expand** — expands the row inline to reveal the full on-chain **Contract Address** (copyable, with a link to the block explorer) and a feed of the latest alerts fired for that specific contract. Click ˄ to collapse.
  </Tab>

  <Tab title="Documentation">
    A free-form documentation area for the project. Click **+ Create documentation** to add notes, runbooks, or compliance evidence. Content is stored per-project within your organization.
  </Tab>

  <Tab title="Tokenomics">
    The Tokenomics tab tracks token supply and distribution health:

    * **Supply Issuance Monitoring** — tracks minting and burning events
    * **Allocations** — breakdown of token allocation categories (vesting, treasury, team, etc.)
    * **Alerts** — tokenomics-specific alerts

    When supply issuance monitoring is not configured, this section shows "Monitoring is disabled."
  </Tab>

  <Tab title="Governance">
    The Governance tab stores governance-related documentation. Click **+ Create documentation** to attach governance policies, voting records, or DAO structure notes.
  </Tab>
</Tabs>


# Resolving Alerts
Source: https://docs.extractor.live/a3-documentation/resolving-alerts

Mark Hacken Extractor alerts as resolved individually, in bulk, or from the Alert Details panel — a guide to closing out detector and trigger events.

## Overview

Resolving an alert marks it as acknowledged and removes it from the active unresolved queue. Resolved alerts are never deleted — they stay in the full history and are accessible via the **Resolved** filter on the Alerts History page.

The same **Alert Details** panel is available from multiple places in the platform, so you can resolve alerts without navigating away from your current context.

## Where you can resolve alerts

### Alerts History

The primary place for alert triage. Two resolution flows are available:

**Single alert** — click any row to open the Alert Details panel, then click **Mark as Resolved**.

**Bulk resolve** — tick the checkboxes on the left of one or more rows. A selection toolbar appears above the table with the following actions:

| Action | Effect |
| - | - |
| **Mark as Resolved** | Resolves all selected alerts at once |
| **Mark as Read** | Marks selected alerts as read without resolving |
| **Mark as Unread** | Marks selected alerts as unread |

### Dashboard

The **Latest Alerts** widget on the Dashboard shows the most recent unresolved alerts. Click any row to open the same Alert Details panel and resolve the alert from there.

### Project Overview

Each project's Overview page includes an **Alerts** section that lists recent alerts grouped by category. Click an alert card to expand it, then click **View Details** to open the Alert Details panel.

## The Alert Details panel

The panel is identical regardless of where it is opened:

| Field | Description |
| - | - |
| **Alert name** | The rule that fired (e.g. `Interaction with suspicious account`) |
| **Context value** | Human-readable metric snapshot or transaction hash |
| **Date and time** | Exact timestamp |
| **Severity** | Color-coded badge: `INFO`, `LOW`, `MEDIUM`, `HIGH`, or `CRITICAL` |
| **Score Change** | Score before → after the alert fired |
| **Alert status** | `UNRESOLVED` (orange) or `RESOLVED` (green) |
| **Raw data** | Key/value pairs of the underlying on-chain data |

Use **Previous** / **Next** in the panel header to step through adjacent alerts without closing the panel.

### Resolving from the panel

1. Open the Alert Details panel for an unresolved alert.
2. Confirm the **Alert status** badge shows `UNRESOLVED`.
3. Click **Mark as Resolved** at the bottom of the panel.
4. The badge changes to `RESOLVED` (green) and the "Mark as Resolved" button is replaced by "Report a Mistake" only.

### Viewing resolved alerts

On the Alerts History page, use the **Alert Status** toggle in the right-hand filter panel to switch between **Resolved** and **Unresolved** views. Resolved rows display a green checkmark icon instead of the info icon shown on unresolved rows.


# Settings
Source: https://docs.extractor.live/a3-documentation/settings

Manage your Hacken Extractor profile, enable two-factor authentication, and configure organization team members and permissions in the Settings page.

<img alt="Settings page showing Profile Settings tab with Default Table Size and Theme options" />

Navigate to **Settings** at the bottom of the left sidebar. Three tabs are available: Profile Settings, Security, and Team.

## Profile Settings

The **Profile Settings** tab contains general UI preferences.

| Setting | Description |
| - | - |
| **Default Table Size** | Number of rows shown per page across all tables. Default is `100 / page`. |
| **Theme** | Toggle between **Light** and **Dark** mode. Takes effect immediately. |

## Security

The **Security** tab manages two-factor authentication (2FA) devices.

* The table lists registered 2FA devices with **Device** and **Enabled** columns.
* If no devices are registered, the table shows "No 2FA devices."
* Click **Add New 2FA Device** to register an authenticator app or hardware key.

<Note>
  Enabling 2FA is strongly recommended for all users with admin or editor roles, as they can modify monitoring configuration, resolve alerts, and manage team access.
</Note>

## Team

The **Team** tab lets organization admins manage workspace access.

### Member List

| Column | Description |
| - | - |
| **Name** | Display name and email address |
| **Status** | `ADMIN` badge for administrators |
| **Role** | Assigned role(s), e.g. `extractor-admin`. Click `[+N]` to see all roles for a member. |

The three-dot menu (⋮) on each row lets admins edit or remove a member.

### Inviting a Team Member

Click **Invite Team Member**, enter the invitee's email and select a role, then send the invitation. The invitee receives an email with a sign-up link.

### Roles

Roles control what actions a user can perform in A3 — for example, whether they can modify monitoring settings or only view dashboards and alerts. Contact your Hacken account manager for the full role permission matrix for your organization.


# Advanced Monitoring
Source: https://docs.extractor.live/advanced-monitoring/intro

Define custom on-chain trigger conditions on your smart contracts with Hacken Extractor Advanced Monitoring and get alerted the moment they are met.

Advanced Monitoring lets you create custom triggers that watch for specific on-chain conditions — a function call, a token transfer, a blacklisted address, or a matching transaction parameter — and fire an alert the instant they occur.

## Available triggers

<CardGroup>
  <Card title="ERC-20 Transfer" icon="money-bill-transfer" href="/advanced-monitoring/triggers/erc20-transfer">
    Fires when a token transfer exceeds a configured amount. Filter by direction (from / to / any) and token contract.
  </Card>

  <Card title="Blacklisted Callers" icon="ban" href="/advanced-monitoring/triggers/blacklisted-callers">
    Fires when a transaction is initiated by an address on your blacklist.
  </Card>

  <Card title="Whitelisted Callers" icon="check" href="/advanced-monitoring/triggers/whitelisted-callers">
    Fires when a transaction is initiated by an address that is NOT on your whitelist — catching unauthorized access.
  </Card>

  <Card title="Failed Transaction" icon="circle-xmark" href="/advanced-monitoring/triggers/failed-transaction">
    Fires when any transaction to the monitored contract fails.
  </Card>

  <Card title="Transaction Parameters" icon="sliders" href="/advanced-monitoring/triggers/transaction-parameters">
    Fires when any transaction parameter (gas, value, sender, block data, receipt fields, etc.) matches rules you define.
  </Card>

  <Card title="Function Call" icon="code" href="/advanced-monitoring/triggers/function-call">
    Fires whenever a specific contract function is executed. Optionally filter by transaction value.
  </Card>

  <Card title="Event Emitted" icon="bell" href="/advanced-monitoring/triggers/event-emitted">
    Fires when a specific event is emitted from the monitored contract. Select the event from the contract ABI.
  </Card>

  <Card title="Event Advanced" icon="magnifying-glass" href="/advanced-monitoring/triggers/event-advanced">
    Fires when an event matching a free-text signature is emitted from any contract address you specify.
  </Card>
</CardGroup>

***

## Triggers tab

The **Triggers** tab on an Advanced Monitoring entity lists all configured triggers.

### Trigger statuses

| Status | Meaning |
| - | - |
| **ENABLED** | Trigger is active and will fire alerts when conditions are met. |
| **DISABLED** | Trigger is manually paused and will not fire. |
| **PAUSED** | System automatically paused the trigger due to excessive alert volume. Re-enable it after reviewing the configuration. |

### Row menu (···)

Each trigger row has a **···** menu with:

| Option | Description |
| - | - |
| **Edit Trigger** | Modify the trigger configuration. |
| **Delete Trigger** | Permanently remove the trigger. |

***

## Common configuration fields

Every trigger shares these base fields:

| Field | Description |
| - | - |
| **Trigger Name** | Descriptive label shown in alerts and the trigger list. |
| **Severity** | `Critical` · `High` · `Medium` · `Low` · `Info` |
| **Notification Channels** | Where alerts are delivered — email, webhook, Slack, PagerDuty, etc. |


# Fungible Token (EIP-20 compatible)
Source: https://docs.extractor.live/advanced-monitoring/recommendations-by-sc-type/fungible-token-eip-20-compatible

Recommended Hacken Extractor triggers for ERC-20 / EIP-20 fungible token contracts — monitor minting, transfers, and supply changes for exploits.

Implementations may have some differences, but all requirements of the [standard](https://eips.ethereum.org/EIPS/eip-20) must be met.

### Monitor the minting of new tokens

**Trigger:** Event Parameter *(coming soon)*

**Parameters:**

* **event:** Transfer
* **argument:** from
* **comparator:** equal to
* **value:** 0x0000000000000000000000000000000000000000

**Severity:** Critical

**Alerts:** On

**Use cases:**

* If your contract involves a one-time minting of the total supply, then minting new tokens after deployment signals an issue in the contract that has been exploited.


# Recommendations by SC type
Source: https://docs.extractor.live/advanced-monitoring/recommendations-by-sc-type/index

Trigger recommendations by smart contract type — guidelines for monitoring tokens, NFTs, vesting, staking, lending, token sales, and yield farming.

This page aims to provide actionable recommendations on how to set up triggers for different types of smart contracts. By following these recommendations, you can effectively monitor your contracts and quickly respond to potential security threats.

Each type of contract has unique security needs, and our recommendations take that into consideration. Whether you're dealing with a staking contract, a yield farming contract, or any other type, these recommendations will help you optimize your trigger setup for the best possible protection.

<CardGroup>
  <Card title="Staking" icon="layer-group" href="/advanced-monitoring/recommendations-by-sc-type/staking">Monitor staking contracts for early withdrawals and reward anomalies.</Card>
  <Card title="Vesting" icon="calendar-check" href="/advanced-monitoring/recommendations-by-sc-type/vesting">Track vesting schedules and early token release events.</Card>
  <Card title="Fungible Token (EIP-20)" icon="coins" href="/advanced-monitoring/recommendations-by-sc-type/fungible-token-eip-20-compatible">Monitor ERC-20 tokens for minting, burning, and transfer anomalies.</Card>
  <Card title="Non-Fungible Token (EIP-721)" icon="image" href="/advanced-monitoring/recommendations-by-sc-type/non-fungible-token-eip-721-compatible">Track NFT minting, transfers, and approval events.</Card>
  <Card title="Yield Farming" icon="seedling" href="/advanced-monitoring/recommendations-by-sc-type/yield-farming">Watch yield farming contracts for liquidity changes and reward drains.</Card>
  <Card title="Lending" icon="hand-holding-dollar" href="/advanced-monitoring/recommendations-by-sc-type/lending">Monitor lending protocols for liquidations and collateral changes.</Card>
  <Card title="Token Sale" icon="ticket" href="/advanced-monitoring/recommendations-by-sc-type/token-sale">Track token sale contracts for contribution limits and fund flows.</Card>
</CardGroup>

<Note>
  This list is not exhaustive. If your contract type is not listed, use the existing recommendations as a starting point for configuring Hacken Extractor monitoring.
</Note>


# Lending
Source: https://docs.extractor.live/advanced-monitoring/recommendations-by-sc-type/lending

Trigger setup recommendations for lending smart contracts — monitor borrow amounts, collateral transfers, and unusual repayment activity for exploits.

Lending smart contracts are smart contracts that enable users to lend and borrow assets.

### Monitor unexpectedly large borrowed amounts

**Trigger:** ERC20 Transfer more than n

**Parameters:**

* **Token address:** the address of the collateral token
* **Amount:** should be 5-10% more than the largest expected deposit
* **Destination:** from

**Severity:** Medium

**Alerts:** On

**Use cases:**

* Borrowing an unusually large amount may be a sign that the attacker has found a vulnerability in the contract and is trying to exploit it.


# Non-Fungible Token (EIP-721 compatible)
Source: https://docs.extractor.live/advanced-monitoring/recommendations-by-sc-type/non-fungible-token-eip-721-compatible

Recommended Hacken Extractor triggers for ERC-721 / EIP-721 NFT contracts — monitor mints, transfers, and supply anomalies that signal exploits.

Implementations may have some differences, but all requirements of the [standard](https://eips.ethereum.org/EIPS/eip-721) must be met.

### Monitor the minting of new tokens

**Trigger:** Event Parameter *(coming soon)*

**Parameters:**

* **event:** Transfer
* **argument:** from
* **comparator:** equal to
* **value:** 0x0000000000000000000000000000000000000000

**Severity:** Critical

**Alerts:** On

**Use cases:**

* If your NFT collection is already complete and you are not expecting any new tokens to be created, then it is particularly important to monitor the creation of new tokens with unique IDs.


# Staking
Source: https://docs.extractor.live/advanced-monitoring/recommendations-by-sc-type/staking

Trigger recommendations for staking smart contracts — monitor early withdrawals, reward emissions, and unusual unstake activity to detect exploits.

A staking contract is a type of smart contract that enables users to hold and lock up a certain amount of cryptocurrency or tokens as collateral in order to participate in a blockchain network's consensus process and earn rewards.

### Monitor withdrawal of tokens before the end of the staking period

**Trigger:** ERC20 Transfer more than n

**Parameters:**

* **Token address:** the address of the collateral token
* **Amount:** should be as low as possible, for example less than the minimum deposit amount
* **Destination:** from

**Severity:** see the use cases

**Alerts:** see the use cases

**Use cases:**

* If a contract prohibits withdrawals before the end of the staking period, triggering this trigger may indicate a vulnerability in the contract. In this case, **we recommend setting the severity to critical and enabling alerts.**
* If a contract allows for early withdrawals, then such a trigger would simply reflect that some users have chosen to withdraw tokens for some reason. In this case, **we recommend setting the severity to low.**

### Monitor unexpectedly large deposit amounts

**Trigger:** ERC20 Transfer more than n

**Parameters:**

* **Token address:** the address of the collateral token
* **Amount:** should be 5-10% more than the largest expected deposit
* **Destination:** to

**Severity:** Medium

**Alerts:** On

**Use cases:**

* Unexpectedly large amount of deposit may be a sign that the attacker has found a vulnerability in the smart contract and is making a large deposit to get more profit from the exploit.

### Monitor withdrawal of an amount that is greater than the largest deposit

**Trigger:** ERC20 Transfer more than n

**Parameters:**

* **Token address:** the address of the collateral token
* **Amount:** should be greater than the largest deposit by at least 1 wei
* **Destination:** from

**Severity:** Critical

**Alerts:** On

**Use cases:**

* If there is a withdrawal from the contract for an amount greater than the largest deposit, then this is a clear sign that the contract has been hacked.


# Token Sale
Source: https://docs.extractor.live/advanced-monitoring/recommendations-by-sc-type/token-sale

Trigger setup recommendations for token sale contracts — monitor early withdrawals, oversold limits, and suspicious transfers during fundraising rounds.

Token Sale is a type of smart contract that is used to facilitate the sale of tokens to investors.

### Monitor withdrawal of funds from the contract before the sale is completed

**Trigger:** ERC20 Transfer more than n

**Parameters:**

* **Token address:** the address of the selling token
* **Amount:** should be as small as possible, e.g. 1 wei
* **Destination:** from

**Severity:** Critical

**Alerts:** On

**Use cases:**

* In most cases, tokens can only be withdrawn after a successful sale. Remove this trigger after the sale is over.

### Monitor withdrawal of tokens for an amount greater than the sale limit

**Trigger:** ERC20 Transfer more than n

**Parameters:**

* **Token address:** the address of the selling token
* **Amount:** should be greater than the sale limit by 1 wei
* **Destination:** from

**Severity:** Critical

**Alerts:** On

**Use cases:**

* If a limit is set for the sale of tokens per account, exceeding this limit signals an issue in the contract.


# Vesting
Source: https://docs.extractor.live/advanced-monitoring/recommendations-by-sc-type/vesting

Trigger recommendations for vesting smart contracts — monitor cliff-period withdrawals, unexpectedly large releases, and other exploit indicators.

A vesting contract is a type of smart contract that is used to manage the release of tokens or other assets to a recipient over a specified period of time.

### Monitor any withdrawals from the contract when the cliff period has not ended

**Trigger:** ERC20 Transfer more than n

**Parameters:**

* **Token address:** the address of the vested token
* **Amount:** should be as small as possible, e.g. 1 wei
* **Destination:** from

**Severity:** Critical

**Alerts:** On

**Use cases:**

* Any withdrawal of funds from the contract before the end of the cliff period clearly signals that there is an issue in the contract and it has been exploited. Remove this trigger after the cliff period is over.

### Monitor unexpected large withdrawals

**Trigger:** ERC20 Transfer more than n

**Parameters:**

* **Token address:** the address of the vested token
* **Amount:** should be greater than the maximum possible amount by 1 wei
* **Destination:** from

**Severity:** Critical

**Alerts:** On

**Use cases:**

* Withdrawing an amount from a contract that exceeds the maximum possible under current vesting rules means that there is an issue with the contract and it has been exploited.

### Set up a list of all beneficiaries

**Trigger:** Whitelisted Callers

**Parameters:**

* **Whitelisted Addresses:** list of addresses of all beneficiaries

**Severity:** Critical

**Alerts:** On

**Use cases:**

* Usually, after the start of vesting, the list of those who interact with the contract is the list of its beneficiaries. If someone not from this list interacts with the contract it could be a sign that the contract has been compromised or hacked in some way.


# Yield Farming
Source: https://docs.extractor.live/advanced-monitoring/recommendations-by-sc-type/yield-farming

Trigger setup recommendations for yield farming contracts — monitor large deposits, oversize withdrawals, and reward anomalies that indicate exploits.

It is a type of smart contract that enables users to earn rewards by providing liquidity to decentralized finance (DeFi) protocols. These rewards may be paid in the form of new tokens, cryptocurrency, or other forms of value.

### Monitor unexpectedly large deposit amounts

**Trigger:** ERC20 Transfer more than n

**Parameters:**

* **Token address:** the address of the collateral token
* **Amount:** should be 5-10% more than the largest expected deposit
* **Destination:** to

**Severity:** Medium

**Alerts:** On

**Use cases:**

* An unexpectedly large amount of deposit may be a sign that the attacker has found a vulnerability in the smart contract and is making a large deposit to get more profit from the exploit.

### Monitor withdrawal of an amount that is greater than the largest deposit

**Trigger:** ERC20 Transfer more than n

**Parameters:**

* **Token address:** the address of the collateral token
* **Amount:** should be greater than the largest deposit by at least 1 wei
* **Destination:** from

**Severity:** Critical

**Alerts:** On

**Use cases:**

* If there is a withdrawal from the contract for an amount greater than the largest deposit, then this is a clear sign that the contract has been hacked.


# Blacklisted Callers
Source: https://docs.extractor.live/advanced-monitoring/triggers/blacklisted-callers

The Blacklisted Callers trigger fires whenever a transaction to your monitored smart contract is initiated by an address on your blacklist.

Maintain a list of known malicious, sanctioned, or otherwise untrusted addresses. Any time one of them interacts with your contract, the trigger fires immediately — before the transaction has any further effect downstream.

<Warning>
  This trigger fires on the **initiating address** (`msg.sender`), not intermediate contracts in a call chain. For full call-chain coverage, pair it with the **AML Detector**.
</Warning>

## Use cases

<CardGroup>
  <Card title="Sanctions enforcement" icon="ban">
    Block or flag interactions from OFAC-listed wallets and known exploit addresses before they can interact with your protocol.
  </Card>

  <Card title="Post-exploit containment" icon="shield-halved">
    After a security incident, add the attacker's addresses to the blacklist immediately. Any follow-up interaction with surviving contracts triggers an instant alert.
  </Card>

  <Card title="Competitor or bot exclusion" icon="robot">
    Track if specific bots or competitor addresses are interacting with your contract at unusual frequency.
  </Card>
</CardGroup>

## Configuration

<Steps>
  <Step title="Name">
    Enter a descriptive label, e.g. `Sanctioned Address Alert`.
  </Step>

  <Step title="Blacklisted entities">
    Comma-separated list of addresses to watch. Any transaction initiated by one of these will fire the trigger:

    ```
    0xd8dA6BF26964aF9D7eEd9e03E53415D37aA96045,
    0xAb5801a7D398351b8bE11C439e05C5B3259aeC9B
    ```
  </Step>
</Steps>

<Tip>
  Keep your blacklist in sync with an external AML feed by periodically updating this field via the API. The **Custom Addresses** option in the AML Detector can automate this for larger lists.
</Tip>


# ERC-20 Transfer
Source: https://docs.extractor.live/advanced-monitoring/triggers/erc20-transfer

The ERC-20 Transfer trigger fires whenever an ERC-20 token transfer above your configured threshold occurs on the monitored smart contract.

Monitor large or suspicious token movements in real time. Configure a minimum transfer amount and the trigger fires the moment it's exceeded — giving your team an instant signal before funds move further.

## Use cases

<CardGroup>
  <Card title="Theft & drain detection" icon="money-bill-transfer">
    Catch abnormally large token outflows the moment they happen. A transfer exceeding your threshold from a contract you monitor is often the first observable sign of an exploit.
  </Card>

  <Card title="Whale movement alerts" icon="fish">
    Track significant holder movements — large transfers from known investor wallets can signal sell pressure or vesting unlocks worth acting on.
  </Card>

  <Card title="Treasury oversight" icon="building-columns">
    Ensure no single transfer from your treasury contract exceeds your defined limits without an alert, regardless of who initiates it.
  </Card>
</CardGroup>

## Configuration

<Steps>
  <Step title="Name">
    Enter a descriptive name, e.g. `Large USDC Outflow`.
  </Step>

  <Step title="Token address">
    The contract address of the ERC-20 token to monitor.

    ```
    0xA0b86991c6218b36c1d19D4a2e9Eb0cE3606eB48
    ```
  </Step>

  <Step title="Amount">
    Minimum transfer amount that triggers an alert. Transfers at or above this value will fire.

    ```
    10000
    ```
  </Step>

  <Step title="Token decimals">
    The decimal precision of the token (e.g. `6` for USDC, `18` for most ERC-20s). Used to interpret the raw on-chain amount correctly.
  </Step>

  <Step title="Transfer direction">
    Choose which side of the transfer to watch:

    | Option | Meaning |
    | - | - |
    | **From** | Alert when the monitored address sends tokens |
    | **To** | Alert when the monitored address receives tokens |
    | **Any** | Alert on either direction |
  </Step>
</Steps>

<Warning>
  Make sure **Token decimals** matches the actual token. An incorrect value will cause the threshold comparison to use the wrong scale and either miss alerts or flood you with noise.
</Warning>


# Event Advanced
Source: https://docs.extractor.live/advanced-monitoring/triggers/event-advanced

Fires when an event matching a free-text signature is emitted from any contract address you specify — not limited to the monitored contract.

**Event Advanced** extends the Event Emitted trigger in two key ways: the event is identified by a free-text signature search rather than a dropdown selection, and it can watch **any** contract address — not just the one you are monitoring. Use this when you need to react to events emitted by external contracts (e.g., a DEX, oracle, or bridge) in the context of your monitored entity.

## Use cases

<AccordionGroup>
  <Accordion title="Cross-contract event monitoring" icon="arrows-left-right">
    Monitor an oracle or price feed contract for its `AnswerUpdated` event and react within the context of your monitored contract.
  </Accordion>

  <Accordion title="DEX and liquidity events" icon="chart-line">
    Watch for `Swap` or `Sync` events on a Uniswap pair contract that is related to your token, even though it is a third-party contract.
  </Accordion>

  <Accordion title="Bridge and relay tracking" icon="bridge">
    Detect cross-chain message events emitted by a bridge contract to correlate with activity on your monitored contract.
  </Accordion>
</AccordionGroup>

## Configuration

<Steps>
  <Step title="Trigger Name">
    Enter a descriptive label, e.g. `Oracle Price Updated`.
  </Step>

  <Step title="Event">
    Search for the event by name or by its keccak-256 signature hash. Unlike **Event Emitted**, this field accepts free-text input and is not limited to the monitored contract's ABI.

    | Search method | Example |
    | - | - |
    | **By name** | `Transfer` — matches `Transfer(address,address,uint256)` |
    | **By signature hash** | `0xe1fffcc4923d04b559f4d29a8bfc6cda04eb5b0d3c460751c2402c5c5cc9109c` |

    <Tip>Use the signature hash when the event name is ambiguous or when you know the exact topic0 from a transaction receipt.</Tip>
  </Step>

  <Step title="Event Address">
    Enter the address of the contract that will emit the event. This can be any contract on the same network — it does not have to be the monitored contract.
  </Step>

  <Step title="Severity">
    Choose the alert severity: `Critical`, `High`, `Medium`, `Low`, or `Info`.
  </Step>

  <Step title="Notification Channels">
    Select one or more channels to receive the alert.
  </Step>
</Steps>

<Info>
  Use **Event Emitted** when you want to watch an event on the contract you are already monitoring. Use **Event Advanced** when the event source is a different contract address.
</Info>


# Event Emitted
Source: https://docs.extractor.live/advanced-monitoring/triggers/event-emitted

The Event Emitted trigger fires when a specific event is emitted from the monitored smart contract — select the event from the contract ABI.

The **Event Emitted** trigger alerts you whenever a particular event is logged by the monitored contract. Events are the standard way Solidity contracts signal state changes, making this trigger the most direct way to monitor your contract's activity.

## Use cases

<AccordionGroup>
  <Accordion title="Token transfer tracking" icon="money-bill-transfer">
    Alert on every `Transfer` event to monitor all token movements in real time.
  </Accordion>

  <Accordion title="Ownership and role changes" icon="user-gear">
    Watch for `OwnershipTransferred` or `RoleGranted` / `RoleRevoked` events to detect any access control changes.
  </Accordion>

  <Accordion title="Pausing and emergency events" icon="circle-pause">
    Catch `Paused` or `Unpaused` events immediately so your team knows when circuit-breaker logic has been activated.
  </Accordion>
</AccordionGroup>

## Configuration

<Steps>
  <Step title="Trigger Name">
    Enter a descriptive label, e.g. `Transfer Event Detected`.
  </Step>

  <Step title="Event">
    Select the event to watch from the dropdown. Events are loaded from the contract's ABI.
  </Step>

  <Step title="Include Transaction Value (optional)">
    Toggle **Include Transaction Value** to only fire when the transaction that emitted the event also carries a native token value meeting a condition:

    | Field | Description |
    | - | - |
    | **Operator** | Comparison to apply: `=`, `!=`, `>`, `>=`, `<`, `<=` |
    | **Transaction value** | Native token amount in wei |

    Leave the toggle off to fire on every event emission regardless of value.
  </Step>

  <Step title="Severity">
    Choose the alert severity: `Critical`, `High`, `Medium`, `Low`, or `Info`.
  </Step>

  <Step title="Notification Channels">
    Select one or more channels to receive the alert.
  </Step>
</Steps>

<Info>
  **Event Emitted** selects events from the monitored contract's ABI. To monitor events on a different contract address, use **Event Advanced** instead.
</Info>


# Failed Transaction
Source: https://docs.extractor.live/advanced-monitoring/triggers/failed-transaction

The Failed Transaction trigger fires when any transaction to the monitored smart contract is reverted or fails on-chain, surfacing exploit attempts.

The **Failed Transaction** trigger alerts you any time a transaction directed at the monitored contract reverts or fails on-chain. Failed transactions often signal attempted exploits, misconfigured callers, or contract logic errors.

## Use cases

<AccordionGroup>
  <Accordion title="Exploit attempt detection" icon="bug">
    Attackers frequently probe contracts with crafted calls that revert. A spike in failed transactions can be an early warning of a targeted attack.
  </Accordion>

  <Accordion title="Integration health" icon="heart-pulse">
    Catch broken integrations or misconfigured bots that are sending transactions with wrong parameters before they cause downstream issues.
  </Accordion>

  <Accordion title="Contract logic errors" icon="triangle-exclamation">
    A regression in contract logic that causes previously valid calls to revert will immediately surface as failed transaction alerts.
  </Accordion>
</AccordionGroup>

## Configuration

<Steps>
  <Step title="Trigger Name">
    Enter a descriptive label, e.g. `Failed Transaction Alert`.
  </Step>

  <Step title="Severity">
    Choose the alert severity: `Critical`, `High`, `Medium`, `Low`, or `Info`.
  </Step>

  <Step title="Notification Channels">
    Select one or more channels to receive the alert (email, Slack, webhook, PagerDuty, etc.).
  </Step>
</Steps>

<Info>
  This trigger has no additional filter fields — it fires on every failed transaction to the monitored contract. Use severity and notification channel settings to control alert routing.
</Info>


# Function Call
Source: https://docs.extractor.live/advanced-monitoring/triggers/function-call

The Function Call trigger fires whenever a specific function is called on the monitored smart contract, optionally filtered by transaction value.

Watch for execution of any contract function — privileged admin calls, user-facing operations, or internal logic. Combine with a transaction value filter to narrow alerts to only the calls that matter.

## Use cases

<AccordionGroup>
  <Accordion title="Privileged function monitoring" icon="lock">
    Functions like `pause()`, `upgradeTo()`, or `transferOwnership()` should almost never be called in normal operation. An alert on these gives you instant visibility into any governance or admin action.
  </Accordion>

  <Accordion title="High-value interactions" icon="coins">
    Combine the function filter with a minimum transaction value to catch large deposits, withdrawals, or swaps through a specific entry point.
  </Accordion>

  <Accordion title="Audit trail" icon="scroll">
    Build a complete call history for any function across your deployment. Useful for post-incident forensics and compliance reporting.
  </Accordion>
</AccordionGroup>

## Configuration

<Steps>
  <Step title="Trigger Name">
    Enter a descriptive label, e.g. `Ownership Transfer Detected`.
  </Step>

  <Step title="Function">
    Select the function to watch from the dropdown. Functions are loaded from the contract's ABI and shown in the format `functionName(argTypes) returnType`.
  </Step>

  <Step title="Include Transaction Value (optional)">
    Toggle **Include Transaction Value** to restrict alerts to calls that carry a native token value meeting a condition:

    | Field | Description |
    | - | - |
    | **Operator** | Comparison to apply: `=`, `!=`, `>`, `>=`, `<`, `<=` |
    | **Transaction value** | Native token amount in wei |

    Leave the toggle off to fire on every call regardless of value.
  </Step>

  <Step title="Severity">
    Choose the alert severity: `Critical`, `High`, `Medium`, `Low`, or `Info`.
  </Step>

  <Step title="Notification Channels">
    Select one or more channels to receive the alert.
  </Step>
</Steps>


# Trigger types
Source: https://docs.extractor.live/advanced-monitoring/triggers/index

Advanced monitoring triggers let you define precise on-chain conditions — function calls, events, transfers, and parameters — that fire real-time alerts.

Triggers watch your smart contracts at the transaction level. Each trigger evaluates a specific condition — a token transfer amount, a function being called, an event being emitted — and fires an alert when that condition is met.

<CardGroup>
  <Card title="ERC20 Transfer" icon="coins" href="/advanced-monitoring/triggers/erc20-transfer">Alert when ERC-20 tokens are transferred above a configured amount.</Card>
  <Card title="Blacklisted Callers" icon="ban" href="/advanced-monitoring/triggers/blacklisted-callers">Alert when a blocked address calls your contract.</Card>
  <Card title="Whitelisted Callers" icon="circle-check" href="/advanced-monitoring/triggers/whitelisted-callers">Alert when an unexpected address calls your contract.</Card>
  <Card title="Failed Transaction" icon="circle-xmark" href="/advanced-monitoring/triggers/failed-transaction">Alert when transactions to your contract fail.</Card>
  <Card title="Transaction Parameters" icon="sliders" href="/advanced-monitoring/triggers/transaction-parameters">Alert based on specific transaction field values.</Card>
  <Card title="Function Call" icon="code" href="/advanced-monitoring/triggers/function-call">Alert when a specific contract function is called.</Card>
  <Card title="Event Emitted" icon="bolt" href="/advanced-monitoring/triggers/event-emitted">Alert when a specific contract event is emitted.</Card>
  <Card title="Event Advanced" icon="wand-magic-sparkles" href="/advanced-monitoring/triggers/event-advanced">Alert on events with parameter-level filtering.</Card>
</CardGroup>


# Transaction Parameters
Source: https://docs.extractor.live/advanced-monitoring/triggers/transaction-parameters

The Transaction Parameters trigger fires when any transaction or block parameter matches one or more rules you define on the monitored contract.

The **Transaction Parameters** trigger gives you granular control over exactly which transactions produce alerts. You can match on any field of the transaction, receipt, or block — from the sender address and gas price to block-level metadata.

## Use cases

<AccordionGroup>
  <Accordion title="Gas price anomaly detection" icon="gauge">
    Alert when a transaction arrives with an unusually high gas price, which can indicate front-running or a misconfigured bot.
  </Accordion>

  <Accordion title="Large value transfers" icon="coins">
    Fire an alert whenever a transaction carries more than a threshold amount of native token (Value field).
  </Accordion>

  <Accordion title="Specific sender monitoring" icon="user">
    Watch for transactions from a particular address without adding it to a blacklist — useful for monitoring partner wallets or known bots.
  </Accordion>

  <Accordion title="Receipt and status checks" icon="receipt">
    Trigger on receipt fields such as gas used or cumulative gas to catch unexpectedly expensive transactions.
  </Accordion>
</AccordionGroup>

## Configuration

<Steps>
  <Step title="Trigger Name">
    Enter a descriptive label, e.g. `High Gas Price Detected`.
  </Step>

  <Step title="From contract (optional)">
    Toggle **From contract** on to restrict the trigger to transactions that originate from a smart contract (i.e., internal calls), rather than externally owned accounts.
  </Step>

  <Step title="Parameters">
    Configure one or more parameter rules. Each rule consists of:

    | Field | Description |
    | - | - |
    | **Parameter** | The transaction/block/receipt field to inspect (see full list below). |
    | **Operator** | Comparison operator: `=`, `!=`, `>`, `>=`, `<`, `<=`, `contains`, `startsWith`, `endsWith`. |
    | **Value** | The value to compare against. |

    Enable **Choose multiple parameters** to add additional rules. Multiple rules are combined with AND logic — all rules must match for the trigger to fire.
  </Step>

  <Step title="Severity">
    Choose the alert severity: `Critical`, `High`, `Medium`, `Low`, or `Info`.
  </Step>

  <Step title="Notification Channels">
    Select one or more channels to receive the alert.
  </Step>
</Steps>

## Available parameters

| Parameter | Description |
| - | - |
| **From** | Sender address of the transaction. |
| **To** | Recipient address of the transaction. |
| **Value** | Native token amount sent with the transaction (in wei). |
| **Gas** | Gas limit set by the sender. |
| **Gas Price** | Gas price set by the sender (in wei). |
| **Max Fee Per Gas** | Maximum total fee per gas unit (EIP-1559). |
| **Max Priority Fee Per Gas** | Maximum priority fee (tip) per gas unit (EIP-1559). |
| **Nonce** | Sender's transaction nonce. |
| **Input** | Raw calldata of the transaction. |
| **Transaction Hash** | Unique hash identifying the transaction. |
| **Transaction Index** | Position of the transaction within its block. |
| **Transaction Type** | Transaction type (0 = legacy, 1 = access list, 2 = EIP-1559). |
| **Timestamp** | Unix timestamp of the block containing the transaction. |
| **Block Number** | Height of the block containing the transaction. |
| **Block Hash** | Hash of the block. |
| **Block Gas Limit** | Maximum gas allowed in the block. |
| **Block Gas Used** | Total gas used by all transactions in the block. |
| **Block Base Fee Per Gas** | Base fee per gas in the block (EIP-1559). |
| **Block Miner** | Address of the block producer. |
| **Block Difficulty** | Proof-of-work difficulty of the block. |
| **Block Total Difficulty** | Cumulative difficulty up to this block. |
| **Block Size** | Size of the block in bytes. |
| **Block Transaction Count** | Number of transactions in the block. |
| **Block Parent Hash** | Hash of the parent block. |
| **Block Nonce** | Block nonce used in proof-of-work. |
| **Block SHA-3 Uncles** | SHA3 hash of the uncle blocks list. |
| **Block State Root** | Root hash of the state trie after the block. |
| **Block Transactions Root** | Root hash of the transactions trie. |
| **Block Receipts Root** | Root hash of the receipts trie. |
| **Block Logs Bloom** | Bloom filter for log entries in the block. |
| **Block Extra Data** | Extra data field set by the block producer. |
| **Receipt Status** | Transaction receipt status (1 = success, 0 = failure). |
| **Receipt Gas Used** | Gas used by this transaction specifically. |
| **Receipt Cumulative Gas Used** | Total gas used in the block up to and including this transaction. |
| **Receipt Effective Gas Price** | Actual gas price paid (base fee + tip). |
| **Receipt Contract Address** | Contract address created by this transaction, if any. |
| **Receipt Root** | Post-transaction state root (pre-Byzantium). |


# Whitelisted Callers
Source: https://docs.extractor.live/advanced-monitoring/triggers/whitelisted-callers

The Whitelisted Callers trigger fires when a transaction is initiated by an address NOT on your whitelist, surfacing unauthorized access attempts.

The **Whitelisted Callers** trigger alerts you any time a transaction reaches the monitored contract from an address that is not in your approved list. This is the inverse of blacklisting — only known, trusted addresses are allowed to interact silently.

## Use cases

<AccordionGroup>
  <Accordion title="Access control enforcement" icon="lock">
    Confirm that only authorized operators, bots, or contracts interact with privileged functions. Any unexpected caller immediately triggers an alert.
  </Accordion>

  <Accordion title="Protocol perimeter monitoring" icon="shield">
    Ensure only whitelisted integrations (e.g., your own frontend router or partner contracts) reach the contract. Catches routing bugs and front-running bots.
  </Accordion>

  <Accordion title="Incident response" icon="triangle-exclamation">
    After a security incident, lock down interaction to a minimal whitelist while you investigate, and get alerted to any attempt to bypass it.
  </Accordion>
</AccordionGroup>

## Configuration

<Steps>
  <Step title="Trigger Name">
    Enter a descriptive label, e.g. `Unauthorized Caller Detected`.
  </Step>

  <Step title="Whitelisted Entities">
    Add one or more wallet addresses that are **allowed** to interact with the contract. Any transaction from an address not on this list will trigger an alert.

    You can add multiple addresses — use the multi-select field to build the full list.
  </Step>

  <Step title="Severity">
    Choose the alert severity: `Critical`, `High`, `Medium`, `Low`, or `Info`.
  </Step>

  <Step title="Notification Channels">
    Select one or more channels to receive the alert (email, Slack, webhook, PagerDuty, etc.).
  </Step>
</Steps>

<Warning>
  An empty whitelist means **every** caller is unauthorized. Make sure to add all legitimate addresses before enabling this trigger, or you will receive an alert for every transaction.
</Warning>


# aggregate alerts
Source: https://docs.extractor.live/api-reference/action-route/aggregate-alerts

/openapi.json post /api/v1/action/alert/aggregation
Aggregate using fields from response dto



# Cost estimate
Source: https://docs.extractor.live/api-reference/action-route/cost-estimate

/openapi.json post /api/v1/action/cost
Estimate cost of action execution



# create entity
Source: https://docs.extractor.live/api-reference/action-route/create-entity

/openapi.json post /api/v1/action



# delete entity by id
Source: https://docs.extractor.live/api-reference/action-route/delete-entity-by-id

/openapi.json delete /api/v1/action/{id}



# get entity by id
Source: https://docs.extractor.live/api-reference/action-route/get-entity-by-id

/openapi.json get /api/v1/action/{id}



# Run action
Source: https://docs.extractor.live/api-reference/action-route/run-action

/openapi.json post /api/v1/action/{id}/run
Execute action



# search action alerts
Source: https://docs.extractor.live/api-reference/action-route/search-action-alerts

/openapi.json post /api/v1/action/alert/search
Search by params from response dto. Using tenant auth



# search action alerts per action
Source: https://docs.extractor.live/api-reference/action-route/search-action-alerts-per-action

/openapi.json post /api/v1/action/{id}/alert/search
Search by params from response dto. Using action auth



# search contracts
Source: https://docs.extractor.live/api-reference/action-route/search-contracts

/openapi.json post /api/v1/action/search
Search by params from response dto



# update entity by id
Source: https://docs.extractor.live/api-reference/action-route/update-entity-by-id

/openapi.json put /api/v1/action/{id}



# Change status of interceptors
Source: https://docs.extractor.live/api-reference/admin-route/change-status-of-interceptors

/openapi.json post /api/v1/admin/interceptor/changeStatus
Set status to all triggers from extractor or not from extractor



# Delete alert by id
Source: https://docs.extractor.live/api-reference/admin-route/delete-alert-by-id

/openapi.json delete /api/v1/admin/alert/{uid}
Delete alert by uid. Multiple deletions might occur, as alerts in different index groups could happen to have same uid.



# Sync entries on kafka
Source: https://docs.extractor.live/api-reference/admin-route/sync-entries-on-kafka

/openapi.json post /api/v1/admin/sync/kafka
Scroll entries from db and put them to kafka topic



# Sync trigger on interceptor
Source: https://docs.extractor.live/api-reference/admin-route/sync-trigger-on-interceptor

/openapi.json post /api/v1/admin/sync/trigger/interceptor
Scroll triggers from db and put them to interceptor api



# delete entity by id
Source: https://docs.extractor.live/api-reference/api-key-route/delete-entity-by-id

/openapi.json delete /api/v1/apikey/{id}
Deleted api keys receive "DELETED" status. Plan limitations do not count such api keys.



# generate api key
Source: https://docs.extractor.live/api-reference/api-key-route/generate-api-key

/openapi.json post /api/v1/apikey



# get api key by id
Source: https://docs.extractor.live/api-reference/api-key-route/get-api-key-by-id

/openapi.json get /api/v1/apikey/{id}



# get redis cache value by key
Source: https://docs.extractor.live/api-reference/api-key-route/get-redis-cache-value-by-key

/openapi.json get /api/v1/apikey/cache/{jti}
Redis entry key is api key jti claim (JWT unique identifier). Redis entry value is an api key ID in RDB. Cache contains only revoked api keys, that aren't expired naturally yet. Only admins can access this endpoint.



# search api keys
Source: https://docs.extractor.live/api-reference/api-key-route/search-api-keys

/openapi.json post /api/v1/apikey/search
Search by params from response dto.



# update api key
Source: https://docs.extractor.live/api-reference/api-key-route/update-api-key

/openapi.json put /api/v1/apikey/{id}
Only status and label updates are allowed. Allowed statuses are "ACTIVE" and "DISABLED". When status is updated to "DISABLED" - api key gets revoked.



# Keycloak auth configs for auth page
Source: https://docs.extractor.live/api-reference/auth-route/keycloak-auth-configs-for-auth-page

/openapi.json get /public/config/v1/keycloak



# create entity
Source: https://docs.extractor.live/api-reference/contract-audit-route/create-entity

/openapi.json post /api/v1/audit



# delete entity by id
Source: https://docs.extractor.live/api-reference/contract-audit-route/delete-entity-by-id

/openapi.json delete /api/v1/audit/{id}



# get entity by id
Source: https://docs.extractor.live/api-reference/contract-audit-route/get-entity-by-id

/openapi.json get /api/v1/audit/{id}



# search entities
Source: https://docs.extractor.live/api-reference/contract-audit-route/search-entities

/openapi.json post /api/v1/audit/search
Search by params from response dto



# update entity by id
Source: https://docs.extractor.live/api-reference/contract-audit-route/update-entity-by-id

/openapi.json put /api/v1/audit/{id}



# aggregate trigger alerts per contract
Source: https://docs.extractor.live/api-reference/contract-route/aggregate-trigger-alerts-per-contract

/openapi.json post /api/v1/contract/{id}/trigger/alert/aggregation
Aggregate using fields from response dto. Using contract auth



# aggregate trigger events per contract
Source: https://docs.extractor.live/api-reference/contract-route/aggregate-trigger-events-per-contract

/openapi.json post /api/v1/contract/{id}/trigger/event/aggregation
Aggregate using fields from response dto. Using contract auth



# alerts histogram for this contract
Source: https://docs.extractor.live/api-reference/contract-route/alerts-histogram-for-this-contract

/openapi.json post /api/v1/contract/{id}/histogram



# create entity
Source: https://docs.extractor.live/api-reference/contract-route/create-entity

/openapi.json post /api/v1/contract



# delete abi override by entity id
Source: https://docs.extractor.live/api-reference/contract-route/delete-abi-override-by-entity-id

/openapi.json delete /api/v1/contract/{id}/abi



# delete entity by id
Source: https://docs.extractor.live/api-reference/contract-route/delete-entity-by-id

/openapi.json delete /api/v1/contract/{id}



# delete proxy abi override by entity id
Source: https://docs.extractor.live/api-reference/contract-route/delete-proxy-abi-override-by-entity-id

/openapi.json delete /api/v1/contract/{id}/implAbi



# fetch any contract data
Source: https://docs.extractor.live/api-reference/contract-route/fetch-any-contract-data

/openapi.json post /api/v1/contract/fetch



# get contract with abi by id
Source: https://docs.extractor.live/api-reference/contract-route/get-contract-with-abi-by-id

/openapi.json get /api/v1/contract/{id}/withAbi



# get entity by id
Source: https://docs.extractor.live/api-reference/contract-route/get-entity-by-id

/openapi.json get /api/v1/contract/{id}



# get labels for this contract from labels api
Source: https://docs.extractor.live/api-reference/contract-route/get-labels-for-this-contract-from-labels-api

/openapi.json get /api/v1/contract/{id}/label



# search action alerts per contract
Source: https://docs.extractor.live/api-reference/contract-route/search-action-alerts-per-contract

/openapi.json post /api/v1/contract/{id}/action/alert/search
Search by params from response dto. Using contract auth



# search contracts
Source: https://docs.extractor.live/api-reference/contract-route/search-contracts

/openapi.json post /api/v1/contract/c3/{licenseInstanceId}/search
Search by params from response dto



# search contracts
Source: https://docs.extractor.live/api-reference/contract-route/search-contracts-1

/openapi.json post /api/v1/contract/search
Search by params from response dto



# search resent alerts for this contract
Source: https://docs.extractor.live/api-reference/contract-route/search-resent-alerts-for-this-contract

/openapi.json post /api/v1/contract/{id}/alert



# search score change per contract
Source: https://docs.extractor.live/api-reference/contract-route/search-score-change-per-contract

/openapi.json post /api/v1/contract/{id}/score/search
Search by params from response dto



# search trigger alerts per contract
Source: https://docs.extractor.live/api-reference/contract-route/search-trigger-alerts-per-contract

/openapi.json post /api/v1/contract/{id}/trigger/alert/search
Search by params from response dto. Using contract auth



# search trigger events per contract
Source: https://docs.extractor.live/api-reference/contract-route/search-trigger-events-per-contract

/openapi.json post /api/v1/contract/{id}/trigger/event/search
Search by params from response dto. Using contract auth



# update entity by id
Source: https://docs.extractor.live/api-reference/contract-route/update-entity-by-id

/openapi.json put /api/v1/contract/{id}



# aggregate alerts
Source: https://docs.extractor.live/api-reference/detector-route/aggregate-alerts

/openapi.json post /api/v1/detector/alert/aggregation
Aggregate using fields from response dto



# aggregate detectors
Source: https://docs.extractor.live/api-reference/detector-route/aggregate-detectors

/openapi.json post /api/v1/detector/aggregation
!!!IMPORTANT!!! Use with caution, because usage with JOIN can require aggregate with 'distinct'



# aggregate events
Source: https://docs.extractor.live/api-reference/detector-route/aggregate-events

/openapi.json post /api/v1/detector/event/aggregation
Aggregate using fields from response dto



# create entity
Source: https://docs.extractor.live/api-reference/detector-route/create-entity

/openapi.json post /api/v1/detector



# delete entity by id
Source: https://docs.extractor.live/api-reference/detector-route/delete-entity-by-id

/openapi.json delete /api/v1/detector/{id}



# get entity by id
Source: https://docs.extractor.live/api-reference/detector-route/get-entity-by-id

/openapi.json get /api/v1/detector/{id}



# search alerts
Source: https://docs.extractor.live/api-reference/detector-route/search-alerts

/openapi.json post /api/v1/detector/alert/search
Search by params from response dto



# search detectors
Source: https://docs.extractor.live/api-reference/detector-route/search-detectors

/openapi.json post /api/v1/detector/search
Search by params from response dto



# search events
Source: https://docs.extractor.live/api-reference/detector-route/search-events

/openapi.json post /api/v1/detector/event/search
Search by params from response dto



# Update all detectors of a particular schema id. Main usage is enabling/disabling all detectors of a particular schema id. Only for admin, use with caution!
Source: https://docs.extractor.live/api-reference/detector-route/update-all-detectors-of-a-particular-schema-id-main-usage-is-enablingdisabling-all-detectors-of-a-particular-schema-id-only-for-admin-use-with-caution!

/openapi.json put /api/v1/detector/batch/{schema_id}



# update entity by id
Source: https://docs.extractor.live/api-reference/detector-route/update-entity-by-id

/openapi.json put /api/v1/detector/{id}



# create entity
Source: https://docs.extractor.live/api-reference/detector-schema-route/create-entity

/openapi.json post /api/v1/schema



# delete entity by id
Source: https://docs.extractor.live/api-reference/detector-schema-route/delete-entity-by-id

/openapi.json delete /api/v1/schema/{id}



# get entity by id
Source: https://docs.extractor.live/api-reference/detector-schema-route/get-entity-by-id

/openapi.json get /api/v1/schema/{id}



# search entities
Source: https://docs.extractor.live/api-reference/detector-schema-route/search-entities

/openapi.json post /api/v1/schema/search
Search by params from response dto



# update entity by id
Source: https://docs.extractor.live/api-reference/detector-schema-route/update-entity-by-id

/openapi.json put /api/v1/schema/{id}



# API Reference
Source: https://docs.extractor.live/api-reference/introduction

Interact with the Hacken Extractor REST API to manage projects, contracts, detectors, triggers, and alerts programmatically from your own services.

## Base URL

```
https://extractor.hacken.dev
```

## Authentication

All requests require a Bearer token in the `Authorization` header.

```bash theme={null}
Authorization: Bearer <your-api-key>
```

<Info>
  Generate your API key from the Hacken Extractor dashboard under **Settings → API Keys**.
</Info>

## Response format

All endpoints return JSON. Successful responses use HTTP `200`; errors return a non-2xx status with a descriptive body.

<Tabs>
  <Tab title="Success">
    ```json theme={null}
    {
      "id": 1,
      "name": "My Project",
      "networkStatus": "MAINNET"
    }
    ```
  </Tab>

  <Tab title="Error">
    ```json theme={null}
    {
      "statusCode": 400,
      "message": "Validation failed",
      "errors": ["name must not be empty"]
    }
    ```
  </Tab>
</Tabs>

## Pagination

Search and aggregation endpoints accept `from` and `size` for cursor-style pagination.

| Parameter | Type | Default | Description |
| - | - | - | - |
| `from` | integer | `0` | Starting document offset |
| `size` | integer | `10` | Number of results to return |

## Endpoints

<CardGroup>
  <Card title="Create Project" icon="folder-plus" href="/api-reference/project-route/create-entity">
    `POST /api/v1/project`
  </Card>

  <Card title="Get Project" icon="folder-open" href="/api-reference/project-route/get-entity-by-id">
    `GET /api/v1/project/{id}`
  </Card>

  <Card title="Create Contract" icon="file-code" href="/api-reference/contract-route/create-entity">
    `POST /api/v1/contract`
  </Card>

  <Card title="Get Contract" icon="file-magnifying-glass" href="/api-reference/contract-route/get-entity-by-id">
    `GET /api/v1/contract/{id}`
  </Card>

  <Card title="Search Alerts" icon="magnifying-glass" href="/api-reference/detector-route/search-alerts">
    `POST /api/v1/detector/alert/search`
  </Card>

  <Card title="Aggregate Alerts" icon="chart-bar" href="/api-reference/detector-route/aggregate-alerts">
    `POST /api/v1/detector/alert/aggregation`
  </Card>
</CardGroup>


# delete entity by id
Source: https://docs.extractor.live/api-reference/invite-route/delete-entity-by-id

/openapi.json delete /api/v1/invite/{id}



# get entity by id
Source: https://docs.extractor.live/api-reference/invite-route/get-entity-by-id

/openapi.json get /api/v1/invite/{id}



# Invite user to tenant
Source: https://docs.extractor.live/api-reference/invite-route/invite-user-to-tenant

/openapi.json post /api/v1/invite



# search entities
Source: https://docs.extractor.live/api-reference/invite-route/search-entities

/openapi.json post /api/v1/invite/search
Search by params from response dto



# update entity by id
Source: https://docs.extractor.live/api-reference/invite-route/update-entity-by-id

/openapi.json put /api/v1/invite/{id}



# create entity
Source: https://docs.extractor.live/api-reference/license-instance-meta-route/create-entity

/openapi.json post /api/v1/instance/meta



# delete entity by id
Source: https://docs.extractor.live/api-reference/license-instance-meta-route/delete-entity-by-id

/openapi.json delete /api/v1/instance/meta/{id}



# get entity by id
Source: https://docs.extractor.live/api-reference/license-instance-meta-route/get-entity-by-id

/openapi.json get /api/v1/instance/meta/{id}



# search entities
Source: https://docs.extractor.live/api-reference/license-instance-meta-route/search-entities

/openapi.json post /api/v1/instance/meta/search
Search by params from response dto



# update entity by id
Source: https://docs.extractor.live/api-reference/license-instance-meta-route/update-entity-by-id

/openapi.json put /api/v1/instance/meta/{id}



# aggregate score change per project
Source: https://docs.extractor.live/api-reference/license-instance-route/aggregate-score-change-per-project

/openapi.json post /api/v1/instance/{id}/score/aggregation
Aggregate using fields from response dto. Using contract auth



# create entity
Source: https://docs.extractor.live/api-reference/license-instance-route/create-entity

/openapi.json post /api/v1/instance



# Delete apiv1instance cleanup
Source: https://docs.extractor.live/api-reference/license-instance-route/delete-apiv1instance-cleanup

/openapi.json delete /api/v1/instance/{id}/cleanup



# delete entity by id
Source: https://docs.extractor.live/api-reference/license-instance-route/delete-entity-by-id

/openapi.json delete /api/v1/instance/{id}



# get entity by id
Source: https://docs.extractor.live/api-reference/license-instance-route/get-entity-by-id

/openapi.json get /api/v1/instance/{id}



# search entities
Source: https://docs.extractor.live/api-reference/license-instance-route/search-entities

/openapi.json post /api/v1/instance/search
Search by params from response dto



# search score change per project
Source: https://docs.extractor.live/api-reference/license-instance-route/search-score-change-per-project

/openapi.json post /api/v1/instance/{id}/score/search
Search by params from response dto



# tokenomics table
Source: https://docs.extractor.live/api-reference/license-instance-route/tokenomics-table

/openapi.json get /api/v1/instance/{id}/tokenomics
Tokenomics data aggregated from RDB and ScoreChange



# update entity by id
Source: https://docs.extractor.live/api-reference/license-instance-route/update-entity-by-id

/openapi.json put /api/v1/instance/{id}



# create entity
Source: https://docs.extractor.live/api-reference/license-route/create-entity

/openapi.json post /api/v1/license



# delete entity by id
Source: https://docs.extractor.live/api-reference/license-route/delete-entity-by-id

/openapi.json delete /api/v1/license/{id}



# get entity by id
Source: https://docs.extractor.live/api-reference/license-route/get-entity-by-id

/openapi.json get /api/v1/license/{id}



# search entities
Source: https://docs.extractor.live/api-reference/license-route/search-entities

/openapi.json post /api/v1/license/search
Search by params from response dto



# update entity by id
Source: https://docs.extractor.live/api-reference/license-route/update-entity-by-id

/openapi.json put /api/v1/license/{id}



# create entity
Source: https://docs.extractor.live/api-reference/license-score-group-route/create-entity

/openapi.json post /api/v1/license/score/group



# delete entity by id
Source: https://docs.extractor.live/api-reference/license-score-group-route/delete-entity-by-id

/openapi.json delete /api/v1/license/score/group/{id}



# get entity by id
Source: https://docs.extractor.live/api-reference/license-score-group-route/get-entity-by-id

/openapi.json get /api/v1/license/score/group/{id}



# search entities
Source: https://docs.extractor.live/api-reference/license-score-group-route/search-entities

/openapi.json post /api/v1/license/score/group/search
Search by params from response dto



# update entity by id
Source: https://docs.extractor.live/api-reference/license-score-group-route/update-entity-by-id

/openapi.json put /api/v1/license/score/group/{id}



# list of the event params for the network
Source: https://docs.extractor.live/api-reference/network-route/list-of-the-event-params-for-the-network

/openapi.json get /api/v1/network/{network}/params/event



# list of the operation params for the network
Source: https://docs.extractor.live/api-reference/network-route/list-of-the-operation-params-for-the-network

/openapi.json get /api/v1/network/{network}/params/operation



# list of the transaction params for the network
Source: https://docs.extractor.live/api-reference/network-route/list-of-the-transaction-params-for-the-network

/openapi.json get /api/v1/network/{network}/params



# list of the transaction params for the network
Source: https://docs.extractor.live/api-reference/network-route/list-of-the-transaction-params-for-the-network-1

/openapi.json get /api/v1/network/{network}/params/tx



# aggregate score change per organisation
Source: https://docs.extractor.live/api-reference/organisation-route/aggregate-score-change-per-organisation

/openapi.json post /api/v1/organisation/{id}/score/aggregation
Aggregate using fields from response dto. Using contract auth



# create entity
Source: https://docs.extractor.live/api-reference/organisation-route/create-entity

/openapi.json post /api/v1/organisation



# delete entity by id
Source: https://docs.extractor.live/api-reference/organisation-route/delete-entity-by-id

/openapi.json delete /api/v1/organisation/{id}



# get entity by id
Source: https://docs.extractor.live/api-reference/organisation-route/get-entity-by-id

/openapi.json get /api/v1/organisation/{id}



# search entities
Source: https://docs.extractor.live/api-reference/organisation-route/search-entities

/openapi.json post /api/v1/organisation/search
Search by params from response dto



# search score change
Source: https://docs.extractor.live/api-reference/organisation-route/search-score-change

/openapi.json post /api/v1/organisation/{id}/score/search
Search by params from response dto



# update entity by id
Source: https://docs.extractor.live/api-reference/organisation-route/update-entity-by-id

/openapi.json put /api/v1/organisation/{id}



# usage dashboard
Source: https://docs.extractor.live/api-reference/organisation-route/usage-dashboard

/openapi.json post /api/v1/organisation/{id}/dashboard/{licenseId}



# create entity
Source: https://docs.extractor.live/api-reference/plan-route/create-entity

/openapi.json post /api/v1/plan



# delete entity by id
Source: https://docs.extractor.live/api-reference/plan-route/delete-entity-by-id

/openapi.json delete /api/v1/plan/{id}



# get entity by id
Source: https://docs.extractor.live/api-reference/plan-route/get-entity-by-id

/openapi.json get /api/v1/plan/{id}



# search entities
Source: https://docs.extractor.live/api-reference/plan-route/search-entities

/openapi.json post /api/v1/plan/search
Search by params from response dto



# update entity by id
Source: https://docs.extractor.live/api-reference/plan-route/update-entity-by-id

/openapi.json put /api/v1/plan/{id}



# create entity
Source: https://docs.extractor.live/api-reference/project-documentation-route/create-entity

/openapi.json post /api/v1/project/documentation



# delete entity by id
Source: https://docs.extractor.live/api-reference/project-documentation-route/delete-entity-by-id

/openapi.json delete /api/v1/project/documentation/{id}



# get entity by id
Source: https://docs.extractor.live/api-reference/project-documentation-route/get-entity-by-id

/openapi.json get /api/v1/project/documentation/{id}



# search entities
Source: https://docs.extractor.live/api-reference/project-documentation-route/search-entities

/openapi.json post /api/v1/project/documentation/search
Search by params from response dto



# update entity by id
Source: https://docs.extractor.live/api-reference/project-documentation-route/update-entity-by-id

/openapi.json put /api/v1/project/documentation/{id}



# aggregate score change per project
Source: https://docs.extractor.live/api-reference/project-route/aggregate-score-change-per-project

/openapi.json post /api/v1/project/{id}/score/aggregation
Aggregate using fields from response dto. Using contract auth



# create entity
Source: https://docs.extractor.live/api-reference/project-route/create-entity

/openapi.json post /api/v1/project



# dashboard counters
Source: https://docs.extractor.live/api-reference/project-route/dashboard-counters

/openapi.json post /api/v1/project/dashboard/counter



# dashboard metrics
Source: https://docs.extractor.live/api-reference/project-route/dashboard-metrics

/openapi.json post /api/v1/project/{id}/dashboard



# delete entity by id
Source: https://docs.extractor.live/api-reference/project-route/delete-entity-by-id

/openapi.json delete /api/v1/project/{id}



# get entity by id
Source: https://docs.extractor.live/api-reference/project-route/get-entity-by-id

/openapi.json get /api/v1/project/{id}



# search projects
Source: https://docs.extractor.live/api-reference/project-route/search-projects

/openapi.json post /api/v1/project/c3/{organisationId}/{licenseId}/search
Search by params from response dto



# search projects
Source: https://docs.extractor.live/api-reference/project-route/search-projects-1

/openapi.json post /api/v1/project/search
Search by params from response dto



# search resent alerts for this project
Source: https://docs.extractor.live/api-reference/project-route/search-resent-alerts-for-this-project

/openapi.json post /api/v1/project/{id}/alert



# search score change per project
Source: https://docs.extractor.live/api-reference/project-route/search-score-change-per-project

/openapi.json post /api/v1/project/{id}/score/search
Search by params from response dto



# update entity by id
Source: https://docs.extractor.live/api-reference/project-route/update-entity-by-id

/openapi.json put /api/v1/project/{id}



# usage dashboard split by detector schema name, trigger type, source id
Source: https://docs.extractor.live/api-reference/project-route/usage-dashboard-split-by-detector-schema-name-trigger-type-source-id

/openapi.json post /api/v1/project/{id}/dashboard/usage/detector



# usage dashboard split by severity
Source: https://docs.extractor.live/api-reference/project-route/usage-dashboard-split-by-severity

/openapi.json post /api/v1/project/{id}/dashboard/usage/severity



# First user access
Source: https://docs.extractor.live/api-reference/registration-route/first-user-access

/openapi.json post /api/v1/registration
Used in few ways:
1. If (tenantName and projectName) not empty. Register flow. Register new user with new tenant/project
2. If (tenantName or projectName) is empty. Invite flow. Looking for invite, creating new user to existing tenant




# Invite user to tenant
Source: https://docs.extractor.live/api-reference/registration-route/invite-user-to-tenant

/openapi.json post /api/v1/registration/invite



# create entity
Source: https://docs.extractor.live/api-reference/score-group-route/create-entity

/openapi.json post /api/v1/score/group



# delete entity by id
Source: https://docs.extractor.live/api-reference/score-group-route/delete-entity-by-id

/openapi.json delete /api/v1/score/group/{id}



# get entity by id
Source: https://docs.extractor.live/api-reference/score-group-route/get-entity-by-id

/openapi.json get /api/v1/score/group/{id}



# search entities
Source: https://docs.extractor.live/api-reference/score-group-route/search-entities

/openapi.json post /api/v1/score/group/search
Search by params from response dto



# update entity by id
Source: https://docs.extractor.live/api-reference/score-group-route/update-entity-by-id

/openapi.json put /api/v1/score/group/{id}



# Resolve score change
Source: https://docs.extractor.live/api-reference/score-route/resolve-score-change

/openapi.json post /api/v1/score/{index}/{uid}/resolve
Resolve score change



# Resolve score change in bulk
Source: https://docs.extractor.live/api-reference/score-route/resolve-score-change-in-bulk

/openapi.json post /api/v1/score/resolve/bulk
Resolve score change in bulk



# Update score change
Source: https://docs.extractor.live/api-reference/score-route/update-score-change

/openapi.json put /api/v1/score/{index}/{uid}
Update score change



# Update score change in bulk
Source: https://docs.extractor.live/api-reference/score-route/update-score-change-in-bulk

/openapi.json put /api/v1/score/bulk
Update score change in bulk



# create entity
Source: https://docs.extractor.live/api-reference/subscription-route/create-entity

/openapi.json post /api/v1/subscription



# delete entity by id
Source: https://docs.extractor.live/api-reference/subscription-route/delete-entity-by-id

/openapi.json delete /api/v1/subscription/{id}



# expire subscriptions
Source: https://docs.extractor.live/api-reference/subscription-route/expire-subscriptions

/openapi.json post /api/v1/subscription/expire
Check all the subscriptions for all the tenants and downgrade to Free subscription if needed



# get entity by id
Source: https://docs.extractor.live/api-reference/subscription-route/get-entity-by-id

/openapi.json get /api/v1/subscription/{id}



# search subscriptions
Source: https://docs.extractor.live/api-reference/subscription-route/search-subscriptions

/openapi.json post /api/v1/subscription/search
Search by params from response dto



# update entity by id
Source: https://docs.extractor.live/api-reference/subscription-route/update-entity-by-id

/openapi.json put /api/v1/subscription/{id}



# Get swagger specs openapi
Source: https://docs.extractor.live/api-reference/swagger-specs-route/get-swagger-specs-openapi

/openapi.json get /swagger-specs/{service}/openapi



# delete syslog
Source: https://docs.extractor.live/api-reference/syslog-route/delete-syslog

/openapi.json delete /api/v1/syslog/{index}/{uid}
Delete extractor entity syslog by index and uid



# Marker endpoint for login syslog tracking
Source: https://docs.extractor.live/api-reference/syslog-route/marker-endpoint-for-login-syslog-tracking

/openapi.json post /api/v1/syslog/login



# search syslog
Source: https://docs.extractor.live/api-reference/syslog-route/search-syslog

/openapi.json post /api/v1/syslog/organisation/{id}/search
Search A3 entity syslog by params



# search syslog
Source: https://docs.extractor.live/api-reference/syslog-route/search-syslog-1

/openapi.json post /api/v1/syslog/tenant/{id}/search
Search extractor entity syslog by params



# handle update
Source: https://docs.extractor.live/api-reference/telegram-route/handle-update

/openapi.json post /public/callback/telegram



# create entity
Source: https://docs.extractor.live/api-reference/tenant-destination-route/create-entity

/openapi.json post /api/v1/destination



# delete entity by id
Source: https://docs.extractor.live/api-reference/tenant-destination-route/delete-entity-by-id

/openapi.json delete /api/v1/destination/{id}



# get entity by id
Source: https://docs.extractor.live/api-reference/tenant-destination-route/get-entity-by-id

/openapi.json get /api/v1/destination/{id}



# handle update
Source: https://docs.extractor.live/api-reference/tenant-destination-route/handle-update

/openapi.json post /api/v1/destination/callback/slack



# search entities
Source: https://docs.extractor.live/api-reference/tenant-destination-route/search-entities

/openapi.json post /api/v1/destination/search
Search by params from response dto



# update entity by id
Source: https://docs.extractor.live/api-reference/tenant-destination-route/update-entity-by-id

/openapi.json put /api/v1/destination/{id}



# create entity
Source: https://docs.extractor.live/api-reference/tenant-route/create-entity

/openapi.json post /api/v1/tenant



# delete entity by id
Source: https://docs.extractor.live/api-reference/tenant-route/delete-entity-by-id

/openapi.json delete /api/v1/tenant/{id}



# get entity by id
Source: https://docs.extractor.live/api-reference/tenant-route/get-entity-by-id

/openapi.json get /api/v1/tenant/{id}



# Networks of from contracts of this tenant
Source: https://docs.extractor.live/api-reference/tenant-route/networks-of-from-contracts-of-this-tenant

/openapi.json get /api/v1/tenant/{id}/networks



# search tenants
Source: https://docs.extractor.live/api-reference/tenant-route/search-tenants

/openapi.json post /api/v1/tenant/search
Search by params from response dto



# Telemetry data from Prometheus
Source: https://docs.extractor.live/api-reference/tenant-route/telemetry-data-from-prometheus

/openapi.json get /api/v1/tenant/telemetry



# Telemetry data from Prometheus. If start and end is set to millis, histogram response will 'extends bounds'
Source: https://docs.extractor.live/api-reference/tenant-route/telemetry-data-from-prometheus-if-start-and-end-is-set-to-millis-histogram-response-will-extends-bounds

/openapi.json post /api/v1/tenant/telemetry



# update entity by id
Source: https://docs.extractor.live/api-reference/tenant-route/update-entity-by-id

/openapi.json put /api/v1/tenant/{id}



# usage dashboard
Source: https://docs.extractor.live/api-reference/tenant-route/usage-dashboard

/openapi.json post /api/v1/tenant/{id}/dashboard/usage



# create entity
Source: https://docs.extractor.live/api-reference/tokenomics-category-route/create-entity

/openapi.json post /api/v1/tokenomics/category



# delete entity by id
Source: https://docs.extractor.live/api-reference/tokenomics-category-route/delete-entity-by-id

/openapi.json delete /api/v1/tokenomics/category/{id}



# get entity by id
Source: https://docs.extractor.live/api-reference/tokenomics-category-route/get-entity-by-id

/openapi.json get /api/v1/tokenomics/category/{id}



# search entities
Source: https://docs.extractor.live/api-reference/tokenomics-category-route/search-entities

/openapi.json post /api/v1/tokenomics/category/search
Search by params from response dto



# update entity by id
Source: https://docs.extractor.live/api-reference/tokenomics-category-route/update-entity-by-id

/openapi.json put /api/v1/tokenomics/category/{id}



# create entity
Source: https://docs.extractor.live/api-reference/tokenomics-schedule-route/create-entity

/openapi.json post /api/v1/tokenomics/schedule



# delete entity by id
Source: https://docs.extractor.live/api-reference/tokenomics-schedule-route/delete-entity-by-id

/openapi.json delete /api/v1/tokenomics/schedule/{id}



# get entity by id
Source: https://docs.extractor.live/api-reference/tokenomics-schedule-route/get-entity-by-id

/openapi.json get /api/v1/tokenomics/schedule/{id}



# search entities
Source: https://docs.extractor.live/api-reference/tokenomics-schedule-route/search-entities

/openapi.json post /api/v1/tokenomics/schedule/search
Search by params from response dto



# update entity by id
Source: https://docs.extractor.live/api-reference/tokenomics-schedule-route/update-entity-by-id

/openapi.json put /api/v1/tokenomics/schedule/{id}



# aggregate alerts
Source: https://docs.extractor.live/api-reference/trigger-route/aggregate-alerts

/openapi.json post /api/v1/trigger/alert/aggregation
Aggregate using fields from response dto



# aggregate events
Source: https://docs.extractor.live/api-reference/trigger-route/aggregate-events

/openapi.json post /api/v1/trigger/event/aggregation
Aggregate using fields from response dto



# create entity
Source: https://docs.extractor.live/api-reference/trigger-route/create-entity

/openapi.json post /api/v1/trigger



# delete entity by id
Source: https://docs.extractor.live/api-reference/trigger-route/delete-entity-by-id

/openapi.json delete /api/v1/trigger/{id}



# get entity by id
Source: https://docs.extractor.live/api-reference/trigger-route/get-entity-by-id

/openapi.json get /api/v1/trigger/{id}



# search alerts
Source: https://docs.extractor.live/api-reference/trigger-route/search-alerts

/openapi.json post /api/v1/trigger/alert/search
Search by params from response dto



# search events
Source: https://docs.extractor.live/api-reference/trigger-route/search-events

/openapi.json post /api/v1/trigger/event/search
Search by params from response dto



# search triggers
Source: https://docs.extractor.live/api-reference/trigger-route/search-triggers

/openapi.json post /api/v1/trigger/search
Search by params from response dto



# update entity by id
Source: https://docs.extractor.live/api-reference/trigger-route/update-entity-by-id

/openapi.json put /api/v1/trigger/{id}



# configure OTP
Source: https://docs.extractor.live/api-reference/user-route/configure-otp

/openapi.json post /api/v1/user/{id}/otp/email
Send email with OTP configuration link to the user



# Delete apiv1user
Source: https://docs.extractor.live/api-reference/user-route/delete-apiv1user

/openapi.json delete /api/v1/user/{id}



# Delete apiv1user cleanup
Source: https://docs.extractor.live/api-reference/user-route/delete-apiv1user-cleanup

/openapi.json delete /api/v1/user/{id}/cleanup



# delete OTP
Source: https://docs.extractor.live/api-reference/user-route/delete-otp

/openapi.json delete /api/v1/user/{id}/otp/{credentialId}
Delete OTP. TOTP code should be passed in payload to perform operation from non-admin roles.



# Get apiv1user
Source: https://docs.extractor.live/api-reference/user-route/get-apiv1user

/openapi.json get /api/v1/user/{id}



# Get apiv1userme
Source: https://docs.extractor.live/api-reference/user-route/get-apiv1userme

/openapi.json get /api/v1/user/me



# get OTP configuration
Source: https://docs.extractor.live/api-reference/user-route/get-otp-configuration

/openapi.json get /api/v1/user/{id}/otp/setup
Get QR code and Base32-encoded secret. Base32-encoded secret can be used in authenticator apps as-is, no decoding required.



# is OTP enabled
Source: https://docs.extractor.live/api-reference/user-route/is-otp-enabled

/openapi.json get /api/v1/user/{id}/otp/enabled
Returns true if OTP is enabled, false if not



# list OTPs
Source: https://docs.extractor.live/api-reference/user-route/list-otps

/openapi.json get /api/v1/user/{id}/otp
Get a list of all configured OTPs for given user



# Put apiv1user
Source: https://docs.extractor.live/api-reference/user-route/put-apiv1user

/openapi.json put /api/v1/user/{id}



# search users
Source: https://docs.extractor.live/api-reference/user-route/search-users

/openapi.json post /api/v1/user/search
Search by params from response dto



# setup OTP
Source: https://docs.extractor.live/api-reference/user-route/setup-otp

/openapi.json post /api/v1/user/{id}/otp/setup
Setup OTP. Secret must be provided to OtpDataDto in base32-encoded format, just like it comes from GET /{id}/otp/setup method. Device name is arbitrary. Same secret could be used for multiple device names. Same secret could not be used for same device name.



# sync roles
Source: https://docs.extractor.live/api-reference/user-route/sync-roles

/openapi.json post /api/v1/user/sync
Sync db user roles with keycloak



# validate OTP
Source: https://docs.extractor.live/api-reference/user-route/validate-otp

/openapi.json post /api/v1/user/{id}/otp/{credentialId}/validate
Validate OTP. Returns true if OTP code is valid, and false if not.



# Cost estimate
Source: https://docs.extractor.live/api-reference/wallet-route/cost-estimate

/openapi.json post /api/v1/wallet/{id}/cost
Estimate cost of action execution



# create entity
Source: https://docs.extractor.live/api-reference/wallet-route/create-entity

/openapi.json post /api/v1/wallet



# delete entity by id
Source: https://docs.extractor.live/api-reference/wallet-route/delete-entity-by-id

/openapi.json delete /api/v1/wallet/{id}



# get entity by id
Source: https://docs.extractor.live/api-reference/wallet-route/get-entity-by-id

/openapi.json get /api/v1/wallet/{id}



# Get wallet balance
Source: https://docs.extractor.live/api-reference/wallet-route/get-wallet-balance

/openapi.json get /api/v1/wallet/{id}/balance



# search contracts
Source: https://docs.extractor.live/api-reference/wallet-route/search-contracts

/openapi.json post /api/v1/wallet/search
Search by params from response dto



# update entity by id
Source: https://docs.extractor.live/api-reference/wallet-route/update-entity-by-id

/openapi.json put /api/v1/wallet/{id}



# Withdraw cash
Source: https://docs.extractor.live/api-reference/wallet-route/withdraw-cash

/openapi.json post /api/v1/wallet/{id}/withdraw



# New and Beta Features
Source: https://docs.extractor.live/beta-features/index

Preview of new and beta detectors available in Hacken Extractor — early-access monitoring features still being tested before general release.

## Detectors Beta

<CardGroup>
  <Card title="Bubblemaps Monitor" icon="chart-pie" href="/detectors/Bubblemaps/DetectorBubblemaps">
    Monitors coin centralization anomaly using Bubblemaps data.
  </Card>

  <Card title="News Detector" icon="newspaper" href="/detectors/News/DetectorNews">
    Monitors RSS and Reddit news feeds with tag-based filtering.
  </Card>

  <Card title="Cron" icon="clock" href="/detectors/Cron/DetectorCron">
    Simple periodic tasks or event trigger on a cron schedule.
  </Card>

  <Card title="Wallet" icon="wallet" href="/detectors/Wallet/DetectorWallet">Monitors changes to address balances</Card>
  <Card title="Wallet" icon="wallet" href="/detectors/WalletSol/DetectorWalletSol">Monitors address balances changes (Native Balance and SLP balances)</Card>
  <Card title="Transaction Monitor" icon="receipt" href="/detectors/TxSol/DetectorTxSol">Match Solana transactions using ordered `conditions` records.</Card>
  <Card title="Transfers" icon="right-left" href="/detectors/TransferSol/DetectorTransferSol">Monitors funds transfers (both native and tokens)</Card>
  <Card title="Feed" icon="rss" href="/detectors/Feed/DetectorFeed">Detector monitors and procesess feeds via scripts pipeline</Card>
  <Card title="AML Detector" icon="user-shield" href="/detectors/Aml/DetectorAml">Detector monitors transactions for addresses that match AML lists, on EVM and Solana networks</Card>
  <Card title="Fusion Monitor" icon="bolt" href="/detectors/Oneinch/DetectorOneinch">1Inch Fusion Monitor ([https://1inch.io/fusion/](https://1inch.io/fusion/)) Monitor tracks Fusion Orders and allows to detect abnormalities</Card>
  <Card title="Tracker" icon="location-crosshairs" href="/detectors/Tracker/DetectorTracker">Tracks transfers and labels addresses</Card>
  <Card title="Circulation Supply Detector" icon="coins" href="/detectors/CirculationSupplyDetector/DetectorCirculationSupplyDetector">Circulating Supply Detector tracks token minting and burning, calculates the circulating supply, monitors unexpected inflation or deflation...</Card>
</CardGroup>


# Common Configurations
Source: https://docs.extractor.live/common-configurations

Shared configuration options available across all Hacken Extractor detectors and triggers — name, severity, alerts, cron, networks, and notifications.

## Severity

Every alert is assigned a severity level, either set manually or determined automatically by the detector.

| Level | Meaning |
| - | - |
| `CRITICAL` | Immediate reaction required — treat as an active incident |
| `HIGH` | Dangerous event that needs prompt attention and resolution |
| `MEDIUM` | Important or suspicious event worth investigating |
| `LOW` | Informational event that may provide useful insights or metrics |
| `INFO` | Progress or state notification only |
| `Auto` | Detector chooses severity based on its own logic; overriding this forces all alerts to the selected level |

<Info>
  When a detector is set to **Auto**, it may emit alerts at different severity levels depending on conditions. Overriding forces a fixed level across all alerts from that detector.
</Info>

***

## Cron Schedule

Controls how frequently a detector evaluates. Three formats are accepted:

<Tabs>
  <Tab title="Human readable">
    Plain-language intervals — easiest to read and configure.

    ```
    10 min
    1 day
    2 hours
    30 seconds
    ```
  </Tab>

  <Tab title="Quartz cron">
    Full [Quartz cron](https://www.quartz-scheduler.org/documentation/quartz-2.3.0/tutorials/crontrigger.html) expression syntax for precise scheduling.

    ```
    0 0 12 * * ?       every day at noon
    0 0/5 * * * ?      every 5 minutes
    0 0 0 ? * MON-FRI  weekdays at midnight
    ```
  </Tab>

  <Tab title="Milliseconds">
    Raw millisecond interval — useful for programmatic configuration via the API.

    ```
    60000     1 minute
    3600000   1 hour
    86400000  1 day
    ```
  </Tab>
</Tabs>

***

## Condition (Threshold)

Conditions control when a detector fires based on a numeric value. The syntax supports basic comparisons, percentage changes, delta operations, and edge-detection operators.

<AccordionGroup>
  <Accordion title="Basic comparison" icon="equals">
    Standard numeric comparison against a fixed value.

    ```
    = 100     fires when value equals 100
    != 100    fires when value does not equal 100
    > 50      fires when |value| > 50
    < 25      fires when |value| < 25
    >= 35     fires when |value| >= 35
    <= 50     fires when |value| <= 50
    ```

    <Tip>Operators `>`, `<`, `>=`, `<=` apply **absolute value handling** by default. Prefix with `+` or `-` to compare exact signed values instead.</Tip>
  </Accordion>

  <Accordion title="Explicit sign (no absolute value)" icon="plus-minus">
    Prefix the threshold with `+` or `-` to skip absolute value handling and compare the exact signed value.

    ```
    > +10     fires when value > 10 (exact, positive only)
    > -15     fires when value > -15
    < +30     fires when value < 30
    < -20     fires when value < -20
    ```
  </Accordion>

  <Accordion title="Percentage change" icon="percent">
    Fires based on the percentage change from the previous value. Formula: `(v - v₀) / v₀ × 100`.

    ```
    > 25%     change > 25%
    < 10%     change < 10%
    >= 50%    change >= 50%
    = 100%    exact 100% change
    ```

    **Example:** if `v₀ = 1000` and `v = 700`, the change is `-30%`.
  </Accordion>

  <Accordion title="Delta (absolute change)" icon="arrow-up-arrow-down">
    Fires based on the absolute change from the previous value using `++` (increase) or `--` (decrease).

    ```
    > ++100    increase greater than 100
    < --50     decrease greater than 50
    >= ++30    increase of at least 30
    = ++20     increase of exactly 20
    ```
  </Accordion>

  <Accordion title="Once operators (edge detection)" icon="arrow-right-to-bracket">
    `>>` and `<<` variants fire **only once** when a condition transitions from false to true. Subsequent evaluations return false even if the condition remains true — useful for detecting threshold crossings without repeated alerts.

    ```
    >> 10     fires once when value crosses above 10
    << 25     fires once when value crosses below 25
    >>= 10    fires once when value reaches or exceeds 10
    <<= 25    fires once when value reaches or falls below 25
    >> ++100  fires once when increase crosses 100
    >> 25%    fires once when percentage change crosses 25%
    ```
  </Accordion>

  <Accordion title="Max/Min operators" icon="chart-line">
    `>>>` and `<<<` variants fire only when a **new all-time maximum or minimum** is reached above/below the threshold.

    ```
    >>> 100    new maximum above 100
    <<< 50     new minimum below 50
    >>>= 100   new maximum at or above 100
    <<<= 50    new minimum at or below 50
    ```

    **Example for `>>> 100`:**

    | Value | Fires? | Reason |
    | - | - | - |
    | 90 | No | Below threshold |
    | 200 | Yes | First value exceeding 100 |
    | 150 | No | Above 100 but below previous max (200) |
    | 300 | Yes | New maximum |
    | 200 | No | Below current max (300) |
  </Accordion>
</AccordionGroup>

<Info>
  Spaces in condition expressions are ignored — `> ++ 100` and `>++100` are equivalent.
</Info>


# Aster DEX Monitor
Source: https://docs.extractor.live/compliance-monitoring/detectors/asterdex-monitor

Monitors Asterdex DEX for portfolio value changes and market price drops. Supports portfolio monitoring (requires API key), market monitoring (public data), or both.

Monitors Asterdex DEX for portfolio value changes and market price drops. Supports portfolio monitoring (requires API key), market monitoring (public data), or both.

## Functionality

* A monitoring service that tracks portfolio values and market prices on Aster DEX, alerting when thresholds are breached.
* Two modes: 'portfolio' (monitors account balance value) or 'market' (monitors price changes). To monitor both, create two separate detector instances with different modes.
* The monitor generates events for: portfolio value falling below threshold, significant price drops in monitored assets, and API connection errors.
* API keys are required for 'portfolio' mode. Market monitoring only uses public endpoints and doesn't require authentication.
* The detector runs on a configurable interval (default: 600 seconds / 10 minutes). You can adjust the check\_interval parameter to customize the monitoring frequency. Each check evaluates all configured conditions for portfolio thresholds and/or price drops depending on the monitoring mode. Minimum recommended: 60 seconds to avoid API rate limits.
* # SUPPORTED SYNTAX

## 1. BASIC COMPARISON OPERATORS

| Syntax | Meaning |
| - | - |
| `= value` | equals value (exact match) |
| `!= value` | not equals value (exact match) |

## 2. ABSOLUTE VALUE HANDLING

| Syntax | Meaning |
| - | - |
| `> 10` | `v > 10` **OR** `v < -10` (absolute value handling) |
| `< 25` | `\|v\| < 25` |
| `>= 35` | `\|v\| >= 35` |
| `<= 50` | `\|v\| <= 50` |

## 3. EXPLICIT SIGN HANDLING (no absolute value)

| Syntax | Meaning |
| - | - |
| `> +10` | `v > 10` (exact value, no absolute handling) |
| `> -15` | `v > -15` (exact value, no absolute handling) |
| `< +30` | `v < 30` (exact value, no absolute handling) |
| `< -20` | `v < -20` (exact value, no absolute handling) |

## 3.5. ONCE OPERATORS (edge detection – trigger only when condition transitions from false to true)

| Syntax | Meaning |
| - | - |
| `>> 10` | `v > 10` (triggers only once when condition becomes true, then false on subsequent evaluations) |
| `<< 25` | `v < 25` (triggers only once when condition becomes true, then false on subsequent evaluations) |
| `>> ++100` | increase > 100 (triggers only once when the increase condition becomes true) |
| `<< --50` | decrease > 50 (triggers only once when the decrease condition becomes true) |
| `>> 25%` | percentage change > 25% (triggers only once when condition becomes true) |
| `<< 10%` | percentage change \< 10% (triggers only once when condition becomes true) |

> **Note:**
>
> * These operators return `true` only when the condition transitions from false → true (edge detection).
> * Once true, subsequent evaluations return false even if the condition remains true.
> * Useful for detecting **threshold crossings** or **one-time events**.

## 4. PERCENTAGE OPERATIONS

| Syntax | Meaning |
| - | - |
| `> 25%` | percentage change > 25% (absolute value handling) |
| `< 10%` | percentage change \< 10% (absolute value handling) |
| `>= 50%` | percentage change >= 50% (absolute value handling) |
| `<= 75%` | percentage change \<= 75% (absolute value handling) |
| `= 100%` | percentage change = 100% (exact match) |
| `!= 200%` | percentage change != 200% (exact match) |

**Formula:** `(v - v₀) / v₀ * 100`

Examples:

* `v₀ = 1000`, `v = 700` → **-30%** (decreased by 30%)
* `v₀ = 1000`, `v = 1300` → **30%** (increased by 30%)
* `v₀ = 100`, `v = 100` → **0%** (no change)

## 5. DELTA OPERATIONS (change from previous value)

| Syntax | Meaning |
| - | - |
| `> ++100` | increase > 100 (absolute change) |
| `< --50` | decrease > 50 (magnitude of decrease) |
| `>= ++30` | increase >= 30 (absolute change) |
| `<= --25` | decrease >= 25 (magnitude of decrease) |
| `= ++20` | increase = 20 (exact change) |
| `!= ++40` | increase != 40 (exact change) |

## 6. PERCENTAGE DELTA OPERATIONS

| Syntax | Meaning |
| - | - |
| `> ++25%` | increase of percentage change > 25% |
| `< --10%` | decrease of percentage change > 10% |
| `>= ++50%` | increase of percentage change >= 50% |
| `<= --30%` | decrease of percentage change >= 30% |
| `= ++100%` | increase of percentage change = 100% |
| `!= ++200%` | increase of percentage change != 200% |

## 7. SPACES SUPPORT

| Syntax | Meaning |
| - | - |
| `> ++ 100` | increase > 100 (spaces ignored) |
| `<= -- 25` | decrease >= 25 (spaces ignored) |
| `= ++ 30.0 %` | increase = 30% (spaces ignored) |

## NOTES

* `=` and `!=` always use **exact value matching**

* `>`, `<`, `>=`, `<=` respect **absolute value handling**

* `>>`, `<<` (once operators) trigger only on **false → true** transitions

* `++`, `--` (delta operations) work with all comparison operators (including once operators)

* Percentage operations are compatible with all comparison operators

* **Spaces are ignored** during parsing

* The `abs` parameter is automatically detected:
  * `+` / `-` prefixes **disable** absolute value handling

* Once operators trigger only when a condition transitions from false to true (edge detection). For example, '>> 5%' triggers when portfolio change exceeds 5%, but won't trigger again until the change drops below 5% and then exceeds it again. This prevents repeated alerts for the same event. Use > instead of >> if you want alerts every check while the condition is true.

* Use the 'Mock Account Data' field to provide a JSON string with fake balance data. When set, the detector skips the /api/v1/account API call and uses your mock data instead. Price data is still fetched from real public endpoints. Format: `{"balances": [{"asset": "BTC", "free": "100", "locked": "0"}]}`

## Configuration

* **API Key (Portfolio mode)** (`api_key`, default: `None`): Asterex API key for authentication
* **API Secret (Portfolio mode)** (`api_secret`, default: `None`): Asterex API secret for HMAC SHA256 signature
* **Check Interval (seconds)** (`check_interval`, default: `600`): Time interval between monitoring checks in seconds. Default is 600 seconds (10 minutes). Minimum recommended: 60 seconds to avoid API rate limits.
* **Monitoring Mode** (`monitoring_mode`, default: `portfolio`): Monitoring mode: 'portfolio' or 'market'
* **Monitored Assets - Market mode** (`monitored_assets`, default: `[{'asset': 'BTC', 'condition': '>> 10'}, {'asset': 'BNB', 'condition': '> 5%'}]`): List of assets to monitor with flexible conditions (only used in market mode). Each asset has its own condition. Not needed for portfolio mode.
* **Mock Account Data (Testing Only) - Portfolio mode** (`mock_account_data`, default: `None`): Optional JSON string with mock account balance data for testing. When provided, skips the /api/v1/account API call. Format: `{"balances": [{"asset": "BTC", "free": "100", "locked": "0"}]}`
* **Portfolio Condition - Portfolio mode** (`portfolio_condition`, default: `>> 5%`): Flexible condition using Scala SDK syntax. Examples: >> 5% (alert once when portfolio drops >5%), > 10% (alert every time portfolio changes >10%), \< 10000000 (alert when below $10M), >> ++1000000 (alert once when portfolio increases >$1M)

<Note>
  Supported networks: evm.
</Note>


# Balance Monitor
Source: https://docs.extractor.live/compliance-monitoring/detectors/balance-monitor

The `BalanceMonitor` is a transaction detector that monitors the balance of accounts or contracts (native token and ERC20 tokens) on a blockchain network. It checks if the balance falls below a specified threshold and sends notifications when this occurs.

The `BalanceMonitor` is a transaction detector that monitors the balance of accounts or contracts (native token and ERC20 tokens) on a blockchain network. It checks if the balance falls below a specified threshold and sends notifications when this occurs.

## Functionality

* The `BalanceMonitor` is a transaction detector that monitors the balance of accounts or contracts (native token and ERC20 tokens) on a blockchain network. It checks if the balance falls below a specified threshold and sends notifications when this occurs. The monitor automatically handles configuration changes and incoming transactions. This tool is especially useful for applications where maintaining a minimum balance is critical, such as payment systems, staking wallets, or operational accounts
* The Balance Monitor has the following key features:
* Monitor the balance of accounts or contracts (native token and ERC20 tokens)
* Set a balance threshold for native token and ERC20 tokens
* Set a severity level for notifications
* Automatically handle configuration changes and incoming transactions
* Send notifications when the balance falls below the specified threshold
* The Balance Monitor supports the following address types:
* Native Token
* ERC20 Token
* The following parameters are available for the native token:
* Balance Threshold: The minimum balance required for the account or contract
* Decimals: The number of decimal for the native token
* The following parameters are available for the ERC20 token:
* Address: The ERC20 token address
* Balance Threshold: The minimum balance required for the ERC20 token
* Decimals: The number of decimal for the ERC20 token
* Symbol: The symbol of the ERC20 token
* The `BalanceMonitor` operates in real-time, actively monitoring transactions and blockchain events to ensure timely detection of balance changes. It processes native token transfers as well as ERC20 token transactions.
* Native Token, for transactions involving native tokens:
* The monitor checks the current balance of the relevant address.
* If the balance falls below the configured threshold, a notification is triggered.
  ERC20 Token, for detected TRANSFER events of ERC20 tokens: - The monitor examines the from and to addresses to check if they are in the monitoring list.
* If an address is found, the monitor queries the balance of the specific ERC20 token for that address.
* If the token balance is below the threshold, a notification is sent.

## Configuration

* **Threshold** (`balance_threshold`, default: `200000000000000000`): Balance Threshold
* **Decimals** (`decimals`, default: `18`): Decimals
* **ERC20 Tokens** (`erc20_tokens`, default: `None`): ERC20 Token
* **Severity** (`severity`, default: `-1.0`): Severity See [common configuration](/common-configurations#severity).

<Note>
  Supported networks: evm.
</Note>


# Chainabuse Monitor
Source: https://docs.extractor.live/compliance-monitoring/detectors/chainabuse-monitor

Detector monitors Chainabuse alerts

Detector monitors Chainabuse alerts

## Functionality

* Chainabuse categories list to filter (`PHISHING`,`OTHER_HACK`, ...). Use `!` prefix to exclude category.

If empty, all categories will be alerted

See Chainabuse documentation for supported categories

* Cron expression for interval to check. Reports are cached internally.

Cron expression can be Quartz syntax, milliseconds value or seconds/minutes/hours/days expression (e.g. `5 hours`)

Example: `0 0 12 1/1 * ? *`

## Configuration

* **Category** (`category`, default: \`\`): Categories to filter
* **Cron** (`cron`, default: `1 day`): Check Interval See [common configuration](/common-configurations#cron).
* **Severity** (`severity`, default: `0.2`): Severity See [common configuration](/common-configurations#severity).

<Note>
  No specific network configuration required (Any network).
</Note>


# Chainlink ACE Monitor
Source: https://docs.extractor.live/compliance-monitoring/detectors/chainlink-ace-monitor

Monitors Contract under Chainlink [Automated Compliance Contract](https://chain.link/automated-compliance-engine) Engine. It understands all ACE Entities and can detect configuration changes, policy violations, transfers and contract calls. CCIP Tracking supports tracking any tokens (no monitored address)

Monitors Contract under Chainlink [Automated Compliance Contract](https://chain.link/automated-compliance-engine) Engine.

It understands all ACE Entities and can detect configuration changes, policy violations, transfers and contract calls.

CCIP Tracking supports tracking any tokens (no monitored address)

## Functionality

* * Detects all ACE Events
* Detects all Policy Rejections (Transactions `reverts`)
* Detects Contract token transfers (if token is ERC-20 compatible)
* Detects function calls
* Detects CCIP Transfers
* Track Condition for transfers (e.g. `> 0`)

NOTE: In token denomination (not decimals)

* Track Contract function calls
* Track CCIP Transfers
* Track Failed transactions. Policy Rejections are failed transactions!
* Track ACE Events

## Configuration

* **Description** (`desc`, default: `{reason}{func}{input}{amount} {sym}{err}`): Description pattern
* **Track Failed** (`track_failed`, default: `True`): Track Failed and Rejections
* **Track calls** (`track_calls`, default: `True`): Track Contract calls
* **Track CCIP** (`track_ccip`, default: `True`): Track CCIP Transfers
* **Track Events** (`track_events`, default: `True`): Track ACE Events
* **Track Transfers** (`track_transfers`, default: `> 0`): Track ERC20 Transfers Condition
* **Severity** (`severity`, default: `-1`): Severity See [common configuration](/common-configurations#severity).

<Note>
  Supported networks: ethereum\_sepolia, base\_sepolia.
</Note>


# Contract Call
Source: https://docs.extractor.live/compliance-monitoring/detectors/contract-call

Execute calls to contract function (not transaction), extracts results and check conditions

Execute calls to contract function (not transaction), extracts results and check conditions

## Functionality

* Function to execute.
  It must be a full signature in the [foundry cast](https://getfoundry.sh/cast/reference/cast) format

(e.g. `balanceOf(address)(uint256)`)

* Parameters to pass to the function.
  Parameters can be separated with spaces or new lines.

Tuples must be enclosed in `()`.

Arrays must be enclosed in `[]`

Strings must be enclosed in `""`

Refer to [cast](https://getfoundry.sh/cast/reference/cast) documentation for syntax

* Sender address (optional). If not specified, the contract address will be used as sender.
* Cron interval to execute call (for `cron` **When** mode). Refer to [Cron](https://docs.extractor.live/common-configurations#cron) for more details
* Scripts to execute

Scripts are executed in the order they are specified. Refer to [Scripts](https://docs.extractor.live/common-configurations#condition-threshold) for more details.

Scripts execution result will be in `result` meta field.

* When to execute script:

`block` - every block
`cron` - at cron intervals

* Desciption field pattern. Metadata fields from Alert can be used as Substitutions and must be enclosed in `{}`

Example: `{func}: {result}`

* Generate Alerts on Errors (in Contract Call or Evaluation Script)
* Alert on every Error. If `unchecked`, only new unique Errors will be alerted and duplicates will be omitted

## Configuration

* **When** (`when`, default: `cron`): When to call the contract
* **Cron** (`cron`, default: `10 min`): Interval to execute See [common configuration](/common-configurations#cron).
* **Function** (`func`, default: `None`): Function signature (foundry format)
* **Parameters** (`params`, default: \`\`): Function parameters
* **Sender** (`sender`, default: \`\`): Sender address (optional)
* **Scripts** (`script`, default: `[]`): Scripts to execute
* **Track Errors** (`track_err`, default: `True`): Track Call/Script error
* **Track Errors (always)** (`err_always`, default: `False`): Always Alert on Error
* **Description** (`desc`, default: `{func}: {result}{err}`): Description Pattern
* **Severity** (`severity`, default: `-1`): Severity See [common configuration](/common-configurations#severity).

<Note>
  Supported networks: ethereum, ethereum\_sepolia, hyperevm, base.
</Note>


# Contract Hash Verification
Source: https://docs.extractor.live/compliance-monitoring/detectors/contract-hash-verification

Contract Hash Verification for detecting changes in a contract bytecode

Contract Hash Verification for detecting changes in a contract bytecode

## Functionality

* The contract hash verification detector continuously monitors the Ethereum Virtual Machine (EVM) network for real-time contract upgrade events. It consumes transaction data, specifically looking for an UPGRADED event emitted by smart contracts. Upon detecting an upgrade event, the detector fetches the bytecode of the updated contract, calculates its hash, and compares it with a provided expected hash hash. Any discrepancies trigger a notification, which is sent to Extractor.
* The type of hash function used to calculate the checksum of the compiled bytecode of the smart contract to be verified. Supported hash functions are Keccak and SHA256. Default value is Keccak.
* The Kaccak checksum of the compiled bytecode of the smart contract to be verified
* Perform an initial check to verify the contract bytecode
* No notification is sent in this case, as the process completed successfully without any discrepancies in the contract bytecode
* The contract bytecode mismatched the expected checksum, triggering a notification with details about the discrepancy

## Configuration

* **Hash Type** (`hash_type`, default: `keccak`): Hash Type
* **Contract Bytecode Checksum** (`checksum`, default: `None`): Contract Bytecode Checksum
* **Initial Check** (`initial_check`, default: `True`): Perform initial bytecode check
* **Severity** (`severity`, default: `-1.0`): Severity See [common configuration](/common-configurations#severity).

<Note>
  Supported networks: evm.
</Note>


# Contract Verification
Source: https://docs.extractor.live/compliance-monitoring/detectors/contract-verification

Contract Verification sentry for detecting changes in a contract

Contract Verification sentry for detecting changes in a contract

## Functionality

* The monitor tracks an EVM network for the `Upgraded` event emitted by smart contracts. Upon detecting an `Upgraded` event, the monitor triggers a contract build process to  verify the checksum of the implementation bytecode on the blockchain against a locally compiled version of the bytecode.
* The name of the smart contract to be tracked and verified
* The URL of the Git repository where the smart contract source code is stored.
* The specific commit hash in the Git repository that corresponds to the contract's source code version to be compiled
* The path within the Git repository where the smart contract source code is located. This should be a relative path from the root of the repository.
* No notification is sent in this case, as the process completed successfully without any issues and the locally compiled bytecode matches the bytecode deployed on the blockchain
* The contract build process fails due to issues such as: incorrect repository URL or commit hash, compilation errors due to missing dependencies, syntax errors, or incompatible Solidity versions, incorrect build path or missing source files, etc. As result, the monitor sends a notification with details about the failure
* The build process completes successfully, but the checksum of the compiled bytecode does not match the bytecode on the blockchain. The monitor sends a notification with details about the checksum mismatch

## Configuration

* **Contract Name** (`contract_name`, default: `None`): Contract Name
* **Respository URL** (`repo_url`, default: `None`): Git Repository URL
* **Commit Hash** (`commit_hash`, default: `None`): Git Respository Commit Hash
* **Build Path** (`build_path`, default: `/`): The build path in Git Repository
* **EVM Version** (`evm_version`, default: `None`): Compiler EVM Version
* **Severity** (`severity`, default: `-1.0`): Severity See [common configuration](/common-configurations#severity).

<Note>
  Supported networks: evm.
</Note>


# DNS Monitor
Source: https://docs.extractor.live/compliance-monitoring/detectors/dns-monitor

Detector monitors DNS for potential attacks (like DNS Hijacking)

Detector monitors DNS for potential attacks (like DNS Hijacking)

## Functionality

* Detector monitors WHOIS and DNS server records for changes
* WHOIS is mulitple registries for domains registration infomation
* Nameservers for Domain resolution.

If Nameserver field is empty, it will not be checked.

* List of IP addresses domain is resolved to. Use `,` (semicolon) for mulitple IP addresses
* It is a date when to start alerting about Domain expiration. It should be before Domain expiration date.

Use date format, not time should be specified (e.g. `2026-01-25`)

If no value is specified expiration will not be checked.

* Cron expression (Quartz expression syntax, millisecond value or seconds/minutes/hours expression)

Periodic check example: `10 min`

Cron expression is Quartz syntax example for every hour:  `0 0 0/1 1/1 * ? *`"

## Configuration

* **Cron** (`cron`, default: `10 min`): Cron expression to check DNS See [common configuration](/common-configurations#cron).
* **Domain** (`domain`, default: \`\`): Domain to monitor
* **IP address(s)** (`ip`, default: \`\`): List of expected resolved addresses
* **NS1** (`ns1`, default: \`\`): Nameserver
* **NS2** (`ns2`, default: \`\`): Nameserver
* **NS3** (`ns3`, default: \`\`): Nameserver
* **NS4** (`ns4`, default: \`\`): Nameserver
* **Expiry Alert date** (`expiry_alert`, default: \`\`): The date when to start alerting about expriration
* **Severity** (`severity`, default: `-1`): Severity See [common configuration](/common-configurations#severity).

<Note>
  No specific network configuration required (Any network).
</Note>


# Github Monitor
Source: https://docs.extractor.live/compliance-monitoring/detectors/github-monitor

Monitors Github repository for participation activity (last week and last month commits)

Monitors Github repository for participation activity (last week and last month commits)

## Functionality

* Path to repository. Only `https://` url supported
* Weekly aggregated commit threshdold
* Monthly aggregated commit threshdold
* Cron expression in Quartz syntax, milliseconds value or seconds/minutes/hours/days interval (e.g. `24 hours`)
  Since participation stat is only at weekly interval, Cron expression should be at day interval

Cron interval will be limited to day interval.

* Use custom provided API Token to access private repositories

## Configuration

* **Repository** (`repo`, default: `None`): Repository url
* **Weekly commits** (`commits_week`, default: `<5`): Weekly commits threshoold
* **Monthly commits** (`commits_month`, default: `<50`): Monthly commits
* **Cron** (`cron`, default: `1 day`): Check Interval See [common configuration](/common-configurations#cron).
* **Github Token** (`api_token`, default: `None`): Github API Token with repo scope
* **Severity** (`severity`, default: `-1`): Severity See [common configuration](/common-configurations#severity).

<Note>
  No specific network configuration required (Any network).
</Note>


# Network Monitor
Source: https://docs.extractor.live/compliance-monitoring/detectors/network-monitor

Monitors Remote host connectivity / availability with periodic requests

Monitors Remote host connectivity / availability with periodic requests

## Functionality

* Detector sends `type` requests and optionally parses response within specified timeout

* Url (Address) to monitor

* Request type: `GET`, `POST`, `PUT`, `HEAD`, `OPTIONS`, `PING`, `TCP`.

* PING: checks if host is reachable

* TCP: checks if port is reachable

* Cron interval. Refer to [Cron](https://docs.extractor.live/common-configurations#cron) for more details

* Scripts to execute to process response body.

Scripts are executed in the order they are specified. Refer to [Scripts](https://docs.extractor.live/common-configurations#condition-threshold) for more details.

Scripts execution result will be in `result` meta field.

* Request Body (applicable for `HTTP` requests)
* Request Headers
* Max redirects for HTTP request
* Optional `Authorization:` header. This header is added to the list of Headers
* Latency threshold (condition) in milliseconds to receive response.

Refer to [https://docs.extractor.live/](https://docs.extractor.live/) for threshold expression syntax).

Example: `>1000`

* Score condition if Scripts return score. If condition is not matched, Alert is not generated.

If `score` is empty, score is not verified. Refer to [Score](https://docs.extractor.live/common-configurations#condition-threshold) for more details

* Generate Alerts on Errors (in Script execution)
* Alert on every Error. If `unchecked`, only new unique Errors will be alerted and duplicates will be omitted
* Description template for the Alert description. Can use any meta field as placeholder (e.g. `{result}`)

## Configuration

* **Cron** (`cron`, default: `10 min`): Cron expression See [common configuration](/common-configurations#cron).
* **Url** (`url`, default: \`\`): Url to monitor
* **Request type** (`type`, default: `GET`): Request type
* **Request Body** (`body`, default: \`\`): Request Body
* **Headers** (`headers`, default: `None`): Request Headers
* **Max redirects** (`redirects`, default: `2`): Max redirects
* **Authorization header** (`auth`, default: \`\`): Authorization header
* **Scripts** (`script`, default: `[]`): Scripts to execute
* **Track Successful** (`track_ok`, default: `True`): Track Successful Responses as Alerts
* **Track Errors** (`track_err`, default: `True`): Track Errors as Alerts
* **Track Error (always)** (`err_always`, default: `True`): Always Alert on Error
* **Score** (`score`, default: \`\`): Score condition
* **Latency (msec)** (`latency`, default: `>1000`): Response latency threshold (msec)
* **Description** (`desc`, default: `{status} {err}`): Description
* **Severity** (`severity`, default: `-1`): Severity See [common configuration](/common-configurations#severity).

<Note>
  No specific network configuration required (Any network).
</Note>


# NIST Alerts Monitor
Source: https://docs.extractor.live/compliance-monitoring/detectors/nist-alerts-monitor

Detector monitors CVE Alert notifications Monitor watches new or updated CVE records with NIST NVD enrichment for old or incomplete records

Detector monitors CVE Alert notifications
Monitor watches new or updated CVE records with NIST NVD enrichment for old or incomplete records

## Functionality

* Regexp for `description` field  match.

If empty, any description will match

Expression example: `'(?i).*keycloak.*`

* CVE score filter in range `0` to `10`
* Cron when to check CVE records.

Records are updated approximately every 7 minutes, so cron expression will be limited to minimal 7 minutes interval

Detector will cache previous CVE results. (Example: "0 0/1 \* 1/1 \* ? \*")

## Configuration

* **Score** (`score`, default: `7.5`): CVE Score filter
* **Domain** (`domain`, default: \`\`): Regexp match for CVE description
* **Cron** (`cron`, default: `7 min`): CVE Score filter See [common configuration](/common-configurations#cron).
* **Severity** (`severity`, default: `-1`): Severity See [common configuration](/common-configurations#severity).

<Note>
  No specific network configuration required (Any network).
</Note>


# Price Monitor
Source: https://docs.extractor.live/compliance-monitoring/detectors/price-monitor

Monitors Price changes of the Contract. Contract must be a Token contract (ERC-20 like)

Monitors Price changes of the Contract.

Contract must be a Token contract (ERC-20 like)

## Functionality

* Cron expression can be specified in milliseconds, Quartz expression syntax or seconds/minutes/hours prefix (e.g.  `10 minutes`).

There is an internal throttling with 60 seconds interval, so intervals should be >1 minute

Cron expression is Quartz syntax (ex:  "0 0/10 \* 1/1 \* ? \*" == every 10 minutes)

* Price value threshold for triggering Alerts. (Ex: >5% for percentage or \<200 for absolute values)

Refer to the [documentation](https://docs.extractor.live/) for supported formats

* Supply your own Coingecko API key for faster Cron interval (default minimum is 10 min)
* When to query price:

`cron` - On Cron interval

`block` - On every new block(Useful for Oracle source)

* Where to query price:

`oracle` - On-chain Feed (Chainlink Oracle format)

`coingecko` - Coingecko Feed

* Currency of the price. Default is `usd`. (Refer to CoinGecko documentation for supported currencies)

**NOTE**: Currently supported only for `coingecko` feed.

`oracle` feed requires adding Chainlink Oracle Contracts in configuration

## Configuration

* **Cron expression** (`cron`, default: `10 min`): Cron expression in Quartz format (or milliseconds) See [common configuration](/common-configurations#cron).
* **Price Threshold** (`threshold`, default: \`\`): Price threshold in USD See [common configuration](/common-configurations#condition).
* **API Key** (`api_key`, default: `None`): Custom API Key
* **When** (`when`, default: `cron`): When to query price
* **Source** (`source`, default: `coingecko`): Price feed source
* **Currency** (`currency`, default: `usd`): Price currency
* **Severity** (`severity`, default: `-1`): Severity See [common configuration](/common-configurations#severity).

<Note>
  Supported networks: evm.
</Note>


# Safe Multisig Monitor
Source: https://docs.extractor.live/compliance-monitoring/detectors/safe-multisig-monitor

The Safe Multisig Monitor is a detector that monitors the signers of a Safe Multisig contract and alerts if a signer signes a tx data that differs from the other signers.

The Safe Multisig Monitor is a detector that monitors the signers of a Safe Multisig contract and alerts if a signer signes a tx data that differs from the other signers.

## Functionality

* This is a monitoring service that tracks activities related to a Safe Multisig contract, including signer changes, transaction executions, and confirmation submissions.
* The monitor continuously fetches data from the Safe Multisig contract and triggers events when:
* A new signer is detected.
* A transaction is executed after reaching the required threshold of confirmations.
* A signer submits a confirmation for a pending transaction.
* A submitted Safe transaction hash does not match the expected computed hash.
* A transaction signature does not match the expected signer.
* The monitor generates three types of events:
* Safe Multisig Signer - Triggered when the list of signers is retrieved.
* Safe Multisig Transaction - Triggered when a transaction is fully confirmed and executed.
* Safe Multisig Confirmation - Triggered when a signer submits a confirmation for a pending transaction.
* Safe Multisig Safe Tx Hash Mismatch - Triggered when a submitted Safe transaction hash does not match the expected computed hash.
* Safe Multisig Signature Mismatch - Triggered when a submitted signature does not match the expected signer.
* Safe Multisig Simulation - Triggered when a new transaction is created on Safe.
* * It computes the Safe transaction hash and compares it to the submitted hash to ensure it has not been tampered with.
* It validates the signatures provided for each transaction to ensure authenticity.
* It logs detected mismatches and alerts users when discrepancies occur.

## Configuration

* **Severity** (`severity`, default: `0.5`): Severity See [common configuration](/common-configurations#severity).

<Note>
  Supported networks: ethereum, bsc, polygon, optimism, ethereum\_sepolia, avalanche, base, arbitrum.
</Note>


# Total Supply Monitor
Source: https://docs.extractor.live/compliance-monitoring/detectors/total-supply-monitor

The Total Supply Monitor is a daily monitoring tool designed to track the total supply of a token. It will send alerts if the total supply of the token exceeds the expected value. This monitor offers users insights into token distribution trends and ensuring compliance with time-based reporting needs, helping maintain consistency and transparency in token supply.

The Total Supply Monitor is a daily monitoring tool designed to track the total supply of a token. It will send alerts if the total supply of the token exceeds the expected value. This monitor offers users insights into token distribution trends and ensuring compliance with time-based reporting needs, helping maintain consistency and transparency in token supply.

## Functionality

* The Expected value fields require whole token values, not raw units. This input is compared against the on-chain supply, normalized using the configured Decimals. Ensure the Decimals value is accurate, as incorrect settings will distort the calculated supply magnitude and prevent alerts.

## Configuration

* **Expected Total Supply** (`expected_total_supply`, default: `None`): Expected Total Supply
* **Expected Total Issued Tokens** (`expected_total_issued`, default: `None`): Expected Issued Tokens
* **Token decimals value** (`decimals`, default: `18`): Token decimals value
* **Severity** (`severity`, default: `-1`): Severity See [common configuration](/common-configurations#severity).

<Note>
  Supported networks: evm.
</Note>


# Total Supply Monitor By Allocations
Source: https://docs.extractor.live/compliance-monitoring/detectors/total-supply-monitor-by-allocations

The Total Supply Monitor by Allocations is a detector that monitors the total supply of a token by allocations. It checks the total supply of a token by comparing the expected total supply with the actual total supply.

The Total Supply Monitor by Allocations is a detector that monitors the total supply of a token by allocations. It checks the total supply of a token by comparing the expected total supply with the actual total supply.

## Functionality

* See configuration parameters below.

## Configuration

* **Token decimals value** (`decimals`, default: `18`): Token decimals value
* **Severity** (`severity`, default: `-1`): Severity See [common configuration](/common-configurations#severity).

<Note>
  Supported networks: evm.
</Note>


# Transfer Monitor
Source: https://docs.extractor.live/compliance-monitoring/detectors/transfer-monitor

The Transfer Monitor tracks transfers via monitored contracts, to/from addresses in transaction logs and notify the Extractor if amount exceed predefined threshold.

The Transfer Monitor tracks transfers via monitored contracts, to/from addresses in transaction logs and notify the Extractor if amount exceed predefined threshold.

## Functionality

* To define a threshold, specify the transfer amount that will trigger an alert.  This should be in integer format, for example, 1000000

## Configuration

* **Severity** (`severity`, default: `-1.0`): Severity See [common configuration](/common-configurations#severity).
* **Threshold** (`threshold`, default: `None`): Threshold Amount See [common configuration](/common-configurations#condition).

<Note>
  Supported networks: evm.
</Note>


# Transfers
Source: https://docs.extractor.live/compliance-monitoring/detectors/transfers-detector

Detector monitors asset transfers (both native and tokens) to and from Monitored Address Detector can be used to detect anomolous, frequent, whale transfers. Detector can track `monitored` Address as ERC-20 for Token transfers in addition to `from` and `to` condition.

Detector monitors asset transfers (both native and tokens) to and from Monitored Address

Detector can be used to detect anomolous, frequent, whale transfers.

Detector can track `monitored` Address as ERC-20 for Token transfers in addition to `from` and `to` condition.

## Functionality

* Detector monitors Token transfers (both ERC-20 and Native token supported) for value amount
* List of token addresses to monitor.

For native transfer monitoring, use native token symbol in `address` fields (e.g. `ETH` for Ethereum, `BNB` for BSC network)

* The **Threshold** value is interpreted based on the **Decimals** setting.
  If **Decimals** matches the token's standard precision (e.g. `6` for **USDC**), the input represents *whole tokens* (e.g. `50` equals **50 USDC**).
  If **Decimals** is set to `0`, the input is treated as the smallest unit (*wei*), meaning `50` equals **0.000050 USDC**.

Refer to the documentation for supported formats.

* Track Monitored address in `to`
* Track Monitoed Address in `from`
* Track `frequent` transfers. Parameter specified transfers number threshold within `cron` interval

Value `0` means no tracking

* Track Monitored Address as ERC-20 token for this Token transfers
* Optional `From` address filter.

NOTE: It it is not correlated with `Track From`

* Optional `To` address filter.

NOTE: It it is not correlated with `Track To`

## Configuration

* **Tokens** (`tokens`, default: `[{'symbol': 'USDT', 'address': '0xdAC17F958D2ee523a2206206994597C13D831ec7', 'decimals': 6, 'threshold': '>10000000'}, {'symbol': 'USDC', 'address': '0xA0b86991c6218b36c1d19D4a2e9Eb0cE3606eB48', 'decimals': 6, 'threshold': '>10000000'}, {'symbol': 'WETH', 'address': '0xC02aaA39b223FE8D0A0e5C4F27eAD9083C756Cc2', 'decimals': 18, 'threshold': '>10000'}, {'symbol': 'ETH', 'address': 'ethereum', 'decimals': 18, 'threshold': '>10000'}, {'symbol': 'BNB', 'address': 'BNB', 'decimals': 18, 'threshold': '>100000'}]`): Additional tokens to monitor
* **Track From** (`track_from`, default: `True`): Track From Address
* **Track To** (`track_to`, default: `True`): Track To Address
* **From** (`from`, default: \`\`): From address filter
* **To** (`to`, default: \`\`): To address filter
* **Track Address** (`track_addr`, default: `True`): Track Address as ERC-20 token
* **Description** (`desc`, default: `{action} {dir} {amount} {sym}`): Desription pattern
* **Severity** (`severity`, default: `-1`): Severity See [common configuration](/common-configurations#severity).

<Note>
  Supported networks: zeta, ethereum, bsc, polygon, ethereum\_sepolia, polygon\_amoy, arbitrum, base\_sepolia, hyperevm, base.
</Note>


# TVL Monitor
Source: https://docs.extractor.live/compliance-monitoring/detectors/tvl-monitor

TVL Monitor tracks liquidity changes for ERC20 tokens & contracts by referencing your pre-configured thresholds. If the balance of a particular asset declined below a threshold, Extractor will notify your team.

TVL Monitor tracks liquidity changes for ERC20 tokens & contracts by referencing your pre-configured thresholds. If the balance of a particular asset declined below a threshold, Extractor will notify your team.

## Functionality

* You can monitor two types of assets for TVL monitoring: ERC-20 tokens and Native coin of the network
* To define a ERC-20 token for monitoring you need to specify its address and threshold for Value Locked for that particular asset
* To include Native coin holdings for TVL monitoring you need to click on "Monitoring Native Token" checkbox and to provide a threshold as well.
* To define a threshold, specify the absolute value or the percentage with '%' sign
* No, in the current version, each threshold is set regarding particular asset (ERC-20 token of Native coin)
* No, you will be notified only about balances change of the assets you have specified for the monitoring.

## Configuration

* **Monitoring Tokens** (`tokens`, default: `None`): Monitoring Tokens
* **Native Token** (`native_token_status`, default: `True`): Monitoring Native Token
* **Native Token Threshold** (`native_token_threshold`, default: `1%`): Native Token Threshold, the value can be entered as absolute value or as percentage (with '%' sign)
* **Severity** (`severity`, default: `0.5`): Event Severity See [common configuration](/common-configurations#severity).

<Note>
  Supported networks: evm.
</Note>


# Compliance Monitoring
Source: https://docs.extractor.live/compliance-monitoring/intro

Align your project with DORA, MiCA, and ADGM regulations using Hacken Extractor's compliance monitors and detectors for on-chain risk reporting.

Enhance your Project with Compliance Monitors and Detectors to align with Regulations:

* [DORA](https://www.eiopa.europa.eu/digital-operational-resilience-act-dora_en)
* [MICAR](https://www.esma.europa.eu/esmas-activities/digital-finance-and-innovation/markets-crypto-assets-regulation-mica)
* [ADGM](https://www.adgm.com/initiatives/sustainable-finance/#regulation)

<Info>
  Please note that this feature is in testing mode. If you come across any inaccurate data or false positive notifications, kindly send us an email to notify us.
</Info>


# AML Detector
Source: https://docs.extractor.live/detectors/Aml/DetectorAml

Detector monitors transactions for addresses that match AML lists, across EVM and Solana networks

Detector monitors transactions for addresses that match AML lists.

## Functionality

* Track transaction and event addresses against AML lists, including `exploit` lists.

By default if no severity is defined, Detector will map AML score to Severity.

Address score is not always real-time and thus Detector works as a pre-screening monitor.

Viewing Alert will often query or recalculate the score and it may differ from the pre-screening score.

Since the detector does pre-screening and may not have `scores` for some Addresses, it may not be able to map to Severity automatically. In such case, the address will be at `Info` severity.

* Condition to filter Alerts by score.

Addresses may not always have scores (depends on the `source` of Address information), thus if condition is `> 0`, it will not catch such addresses.

* Track Addresses in Token (Monitored Address) transfers.

`NOTE`: Monitored Address is assumed to be a token address.

* Track transaction Addresses
  * Track `from` Address
  * Track `to` Address
* Track only specified tags condition.

Multiple tags can be specified comma-separated (e.g. `sanctions, exploit`). Negative condition can be specified by prefixing a tag with exclamation mark (e.g. `! sanctions`).

**Tags**:

`cybercrime` - OFAC or other cybercrime activity

`sanctions` - OFAC or other sanctioned entities

`sanctions_exposure` - Indirect exposure to sanctioned entities

`suspicious` - Suspicious activity

`exploit` - Activity in Exploit case

* Multiple custom addresses can be added to tracking, as CSV: `Address, Score, Name, Tags` (`Tags` semicolon-separated, `Score` from 0.0 to 100.0). Example:

<Tabs>
  <Tab title="EVM">
    ```
    0x1049a94a2238297156826cfcd8b35a3c0400ee98, 80.0, Coin, ofac;sanctions
    ```
  </Tab>

  <Tab title="Solana">
    ```
    hntyVP6YFm1Hg25TN9WGLqM12b8TQmcknKrdu1oxWux, 80.0, Coin, ofac;sanctions
    ```
  </Tab>
</Tabs>

* Exclusion Address list (EVM only). List should contain only comma or newline separated addresses (no metadata). `Custom` addresses will be excluded if also added to the `Exclude` list.

## Configuration

* **Description** (`desc`, default: `{addr} {dir} {score}` on EVM, `{addr} {score}` on Solana): Description Template
* **Source** (`src`, default: \`\`, EVM only): AML Provider Filter
* **Tags filter** (`tags`, default: \`\`): List of tags to filter
* **Score condition** (`score`, default: `>= 0.0`): Track Address score condition
* **Track Transaction** (`track_tx`, default: `True`): Track Transaction Addresses
* **Track Token** (`track_tokens`, default: `True`): Track Contract token transfer Addresses
* **Track From** (`track_from`, default: `True`): Track From Address
* **Track To** (`track_to`, default: `True`): Track To Address
* **Custom Addresses** (`custom`, default: \`\`): List of custom AML addresses
* **Exclude Addresses** (`exclude`, default: \`\`, EVM only): List of exclusion addresses
* **Severity** (`severity`, default: `-1`): Severity. See [common configuration](/common-configurations#severity).

<Note>
  Supported networks: ethereum, bsc, polygon, optimism, ethereum\_sepolia, avalanche, arbitrum, base, hyperevm, solana.
</Note>


# Bubblemap Monitor
Source: https://docs.extractor.live/detectors/Bubblemaps/DetectorBubblemaps

The Bubblemap Monitor uses Bubblemaps data to detect token holder centralization anomalies, alerting when concentration risk patterns appear on-chain.

Detector monitors Coin centralization anomaly

## Functionality

* Monitored Address must be a Coin.
* Detector uses multiple sources to evaluate risk score.
* Data inputs: [https://bubblemaps.io](https://bubblemaps.io)
* Condition to filter Alerts score.
* Track Coin Top holders number.
* Track Score update time (can be calculated at different time).
* Cluster size changes condition (number).
* Cluster share changes condition (in `[0..1]` range).
* Track and alert on Errors.

## Configuration

<img alt="DetectorBubblemaps Configuration" />

* **Description** (`desc`, default: `Decentralization: {score}`): Description Template
* **Score** (`condition`, default: `> 0.0`): Score Condition expression
* **Cluster size** (`cluster_size`, default: \`\`): Cluster size condition
* **Cluster share** (`cluster_share`, default: \`\`): Cluster share condition
* **Track Holders** (`track_holders`, default: `5`): Track Top holders number
* **Track Update** (`track_update`, default: `True`): Track Score update
* **Track Errors** (`track_err`, default: `True`): Track Errors
* **Track Errors (always)** (`err_always`, default: `True`): Always alert on Errors
* **Cron** (`cron`, default: `1 hour`): Cron expression
* **Severity** (`severity`, default: `-1`): Severity

## Tags

* [Beta Features](/beta-features/)


# Circulation Supply Detector
Source: https://docs.extractor.live/detectors/CirculationSupplyDetector/DetectorCirculationSupplyDetector

Circulating Supply Detector tracks token minting and burning, calculates the circulating supply, monitors unexpected inflation or deflation and triggers alerts when significant changes occur.

Circulating Supply Detector tracks token minting and burning, calculates the circulating supply, monitors unexpected inflation or deflation and triggers alerts when significant changes occur.

## Functionality

* A locker address is a contract address that holds locked or  vested tokens, which are subtracted from the total circulating  supply to provide a more accurate supply calculation. These  contracts usually hold tokens that are not in active circulation,  such as tokens reserved for future use, team allocations, or vesting  schedules. By excluding these tokens from the circulating supply, the  detector ensures that the supply data reflects only the tokens that  are actively available in the market.
* To define a threshold, specify the percentage value change in the circulating  supply that will trigger an alert. This should be in decimal format, for example,  if you want to monitor a 1% change in circulation supply, use 0.01. For monitoring  drops, you need to specify negative values, like -0.01. This ensures you are notified  only when there are significant changes.
* The inflation/deflation schedule is a list of dates and expected changes in the  circulating supply. Each entry specifies a date (in YYYY-MM-DD format) and an expected  change percentage. Positive values indicate expected inflation, while negative values  indicate expected deflation. The detector compares the actual changes with the expected  values and triggers alerts if the actual change deviates significantly from the expected change.

## Configuration

* **Threshold** (`threshold`, default: `None`): Threshold See [common configuration](/common-configurations#condition).
* **Locker** (`locker_address`, default: `[]`): Locker Address
* **Inflation/Deflation Schedule** (`inflation_deflation_schedule`, default: `[]`): List of expected token address, expected dates and expected changes
* **Severity** (`severity`, default: `-1.0`): Severity See [common configuration](/common-configurations#severity).

<Note>
  Supported networks: evm.
</Note>


# Cron
Source: https://docs.extractor.live/detectors/Cron/DetectorCron

Simple Periodic Tasks or Events Trigger Examples: `Wallet top-up`, `Subscription Payment`, `Contract job execution`

Simple Periodic Tasks or Events Trigger

Examples: `Wallet top-up`, `Subscription Payment`, `Contract job execution`

## Functionality

* Cron interval. Refer to [Cron](https://docs.extractor.live/common-configurations#cron) for syntax

* Arbitrary data input to the Script (will be in `input` variable)

* Scripts to execute

* Generate Alerts on Errors (in Script execution)

* Alert on every Error. If `unchecked`, only new unique Errors will be alerted and duplicates will be omitted

* Description template for the Alert description. Can use any meta field as placeholder (e.g. `{result}`)

## Configuration

* **Cron expression** (`cron`, default: `10 min`): Cron expression See [common configuration](/common-configurations#cron).
* **Data** (`data`, default: `None`): Arbitrary data input to Script
* **Scripts** (`script`, default: `[]`): Scripts to execute
* **Track Errors** (`track_err`, default: `True`): Track Errors as Alerts
* **Track Error (always)** (`err_always`, default: `True`): Always Alert on Error
* **Description** (`desc`, default: `{result}{err}`): Description Pattern
* **Severity** (`severity`, default: `-1`): Severity See [common configuration](/common-configurations#severity).

<Note>
  No specific network configuration required (Any network).
</Note>


# Feed
Source: https://docs.extractor.live/detectors/Feed/DetectorFeed

Detector monitors and procesess feeds via scripts pipeline

Detector monitors and procesess feeds via scripts pipeline

## Functionality

* Detects new messages/events from a feed and uses message data as input to scripts pipeline.

Script results are used to generate alerts. Result can be treated as a score with a final `condition`.

* Cron interval to check for new messages/events. Refer to [Cron](https://docs.extractor.live/common-configurations#cron) for more details
* Feeds URI

Mulitple URI's can be specified with comma separation. If `type` is not specified, feed can be prefixed with type (`rss://`. `atom://`, `reddit://`, `twitter://@channel`)

* Type of feed:
* `rss`
* `atom`
* `reddit`
* `twitter`
* `meltwater`
* Max number of entries per Feed to process
* Message Category filter (comma separated list of categories). If not specified, all messages will be processed.
* Scripts to execute

Scripts are executed in the order they are specified. Refer to [Scripts](https://docs.extractor.live/common-configurations#condition-threshold) for more details.

Scripts execution result will be in `result` meta field.

* Condition to filter Alerts score on `result` (result must be in the range: \[0..1]). Refer to [Condition](https://docs.extractor.live/common-configurations#condition) for more details
* Description template for the Alert description. Can use any meta field as placeholder (e.g. `{result}`)
* Track Errors

Muliple tags can be specified comma-separated (e.g. `sanctions, exploit`)

Negative condition can be specified by prefixing tag with exclamation mark (e.g. `! sanctions`)

**Tags**:

`cybercrime` - OFAC or othe cybercrime activity

`sanctions` - OFAC or other sanctioned entites

`sanctions_exposure` - Indirect exposure to sanctioned entities

`suspicious` - Suspcious activity

`exploit` - Activity in Exploit case

* Track Errors Always

If enabled, the detector will track errors even if the script result is not a score.

* Severity of the Alert. If not specified, the detector will use the severity of the script result.

## Configuration

* **Cron** (`cron`, default: `10 min`): Cron Interval See [common configuration](/common-configurations#cron).
* **Feeds** (`feeds`, default: `rss://https://cointelegraph.com/rss`): Feeds URI
* **Feed type** (`type`, default: `rss`): Feed Type
* **Max** (`max`, default: `10`): Max news
* **Category** (`category`, default: \`\`): Category filter
* **Scripts** (`script`, default: `[]`): Scripts to execute
* **Score condition** (`score`, default: \`\`): Score
* **Track Errors** (`track_err`, default: `True`): Track Errors as Alerts
* **Track Error (always)** (`err_always`, default: `True`): Always Alert on Error
* **Description** (`desc`, default: `{title} {err}`): Description Template
* **Event Type** (`event_type`, default: \`\`): Internal Event Type
* **Event Category** (`event_cat`, default: \`\`): Internal Event Category
* **Event Source ID** (`event_sid`, default: \`\`): Internal Source ID
* **Timeout** (`timeout`, default: `10000`): Timeout
* **Delay** (`delay`, default: `1000`): Delay
* **Severity** (`severity`, default: `-1`): Severity See [common configuration](/common-configurations#severity).

<Note>
  No specific network configuration required (Any network).
</Note>


# News
Source: https://docs.extractor.live/detectors/News/DetectorNews

Detector monitors news feeds

Detector monitors news feeds

## Functionality

* Track news from different feeds
* Feeds URI

Mulitple URI's can be specified with comma separation. If `type` is not specified, feed can be prefixed with type (`rss://`. `reddit://`)

* Cron interval to check for new posts. Refer to [Cron](https://docs.extractor.live/common-configurations#cron) for more details
* Type of news:
* `rss`
* `reddit`
* Max number of entries per Feed
* Message Category filter (comma separated list of categories). If not specified, all messages will be processed.
* Scripts to execute

Scripts are executed in the order they are specified. Refer to [Scripts](https://docs.extractor.live/common-configurations#condition-threshold) for more details.

Scripts execution result will be in `result` meta field.

* Condition to filter Alerts score on `result` (result must be in the range: \[0..1]). Refer to [Condition](https://docs.extractor.live/common-configurations#condition) for more details
* Track Errors

Muliple tags can be specified comma-separated (e.g. `sanctions, exploit`)

Negative condition can be specified by prefixing tag with exclamation mark (e.g. `! sanctions`)

**Tags**:

`cybercrime` - OFAC or othe cybercrime activity

`sanctions` - OFAC or other sanctioned entites

`sanctions_exposure` - Indirect exposure to sanctioned entities

`suspicious` - Suspcious activity

`exploit` - Activity in Exploit case

* Track Errors Always

If enabled, the detector will track errors even if the script result is not a score.

* Severity of the Alert. If not specified, the detector will use the severity of the script result.
* Description template for the Alert description. Can use any meta field as placeholder (e.g. `{title}`)

## Configuration

* **Cron** (`cron`, default: `10 min`): Cron Interval See [common configuration](/common-configurations#cron).
* **Feeds** (`feeds`, default: `https://cointelegraph.com/rss`): Feeds URI
* **Feed type** (`type`, default: `rss`): Feed Type
* **Max** (`max`, default: `10`): Max news
* **Category** (`category`, default: \`\`): Category filter
* **Score condition** (`score`, default: \`\`): Score
* **Scripts** (`script`, default: `[]`): Scripts to execute
* **Track Errors** (`track_err`, default: `True`): Track Errors as Alerts
* **Track Error (always)** (`err_always`, default: `True`): Always Alert on Error
* **Description** (`desc`, default: `{title} {err}`): Description Template
* **Event Type** (`event_type`, default: \`\`): Internal Event Type
* **Event Category** (`event_cat`, default: \`\`): Internal Event Category
* **Event Source ID** (`event_sid`, default: \`\`): Internal Source ID
* **Timeout** (`timeout`, default: `10000`): Timeout
* **Delay** (`delay`, default: `1000`): Delay
* **Severity** (`severity`, default: `-1`): Severity See [common configuration](/common-configurations#severity).

<Note>
  No specific network configuration required (Any network).
</Note>


# Fusion Monitor
Source: https://docs.extractor.live/detectors/Oneinch/DetectorOneinch

1Inch Fusion Monitor ([https://1inch.io/fusion/](https://1inch.io/fusion/)) Monitor tracks Fusion Orders and allows to detect abnormalities

1Inch Fusion Monitor ([https://1inch.io/fusion/](https://1inch.io/fusion/))

Monitor tracks Fusion Orders and allows to detect abnormalities

## Functionality

* Tracks Fusion Orders
* Cron expression in Quartz syntax (ex:  `0 0 0/1 1/1 * ? *` - every hour), frequency in milliseconds or expression (e.g. `1 min`).

**Not used**

* Amount threshold (maker)
* Create events for **filled** Orders
* Create events for **invalid** Orders
* Detector will evaluate risk score of Order (e.g. `addresses`)

## Configuration

* **Amount (Maker)** (`threshold`, default: `>0.0`): Amount threshold for Maker See [common configuration](/common-configurations#condition).
* **Track Filled** (`track_filled`, default: `False`): Track Filled Order
* **Track Filled Partially** (`track_partially`, default: `False`): Track Filled Partially Order
* **Track Cancelled** (`track_cancelled`, default: `False`): Track Cancelled Order
* **Track Invalid** (`track_invalid`, default: `False`): Track Invalid Order
* **Track Risk** (`track_risk`, default: `False`): Track Order Risks
* **Cron** (`cron`, default: `10 min`): Cron for Stat See [common configuration](/common-configurations#cron).
* **Severity** (`severity`, default: `-1`): Severity See [common configuration](/common-configurations#severity).

<Note>
  Supported networks: ethereum.
</Note>


# Tracker
Source: https://docs.extractor.live/detectors/Tracker/DetectorTracker

Tracks transfers and labels addresses

Tracks transfers and labels addresses

## Functionality

* Track transfers from `Address` list (source addresses) for funds funelling/dispersal

* List of original addresses to track (comma separated)

* Cron to pediodically flush caches and build statistics

(currently does not produce any Events)

* Track Identifier to group label address (e.g. `bybit`).

Mandatory and must be unqiue for every tracker

* Comma-separated list of tags to add to each detected address
* Exclude addresses (with optional labels).

**ATTENTION**:  Each address should be on a new line (it is in `CSV` format)

* Track Native (ETH) transfer
* Tracking threshold for Native tokens
* Tracking threshold  for ERC-20 transfers
* Track ERC-20 tokens transfers

## Configuration

* **Tags list** (`tags`, default: `exploit, suspicious_address`): List of tags
* **Addresses list** (`addr`, default: `0x47666fab8bd0ac7003bce3f5c3585383f09486e2`): List of track addresses
* **Exclude Addresses** (`exclude`, default: `0xf1dA173228fcf015F43f3eA15aBBB51f0d8f1123, eXch
  0xDFaa75323fB721e5f29D43859390f62Cc4B600b8, shuffle.com
  0x29f3bD6461bEcb25A89A576763b2C290EB41E64d,OKXDep-0x29f3b
  0xBf94F0AC752C739F623C463b5210a7fb2cbb420B,OKX-24
  0xf89d7b9c864f589bbF53a82105107622B35EaA40,Bybit-Hot-0xf8`): List exclude addresses (like exchanges)
* **Track Native** (`track_native`, default: `True`): Track native
* **Track Native threshold** (`limit_native`, default: `>1.0`): Native transfer threshold for alert
* **Track ERC20** (`track_tokens`, default: `True`): Track tokens
* **Track ERC20 threshold** (`limit_tokens`, default: `>10.0`): ERC20 transfer threshold for alert
* **Cron** (`cron`, default: `10 min`): Cron expression to check DNS See [common configuration](/common-configurations#cron).
* **Severity** (`severity`, default: `-1`): Severity See [common configuration](/common-configurations#severity).

<Note>
  Supported networks: ethereum, bsc.
</Note>


# Transfers
Source: https://docs.extractor.live/detectors/TransferSol/DetectorTransferSol

Monitors funds transfers (both native and tokens)

Monitors funds transfers (both native and tokens)

## Functionality

* Monitors SLP tokens Transfers and Native transfers.
  It is not associated with monitored Contract and ignores it.
* List of Token addresses to monitor. Use `solana` address for SOL
* Threshold condition to generate Alert. Refert to [Documantion](https://docs.extractor.live/common-configurations#condition-threshold) for `Condition` syntax
* Track Monitored address in `to`
* Track Monitoed Address in `from`
* Track `frequent` transfers. Parameter specified transfers number threshold within `cron` interval

Value `0` means no tracking

* Track Monitored Address as SPL token for this Token transfers
* Optional `From` address filter.

NOTE: It it is not correlated with `Track From`

* Optional `To` address filter.

NOTE: It it is not correlated with `Track To`

* Description pattern

## Configuration

* **Tokens** (`tokens`, default: `[{'symbol': 'SOL', 'address': 'solana', 'decimals': 9, 'condition': '>100'}, {'symbol': 'USDC', 'address': 'EPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1v', 'decimals': 6, 'condition': '> 10000'}, {'symbol': 'USDT', 'address': 'Es9vMFrzaCERmJfrF4H2FYD4KCoNkY11McCe8BenwNYB', 'decimals': 6, 'condition': '> 10000'}]`): Tokens conditions
* **Track From** (`track_from`, default: `True`): Track source address
* **Track To** (`track_to`, default: `True`): Track destination address
* **Track Address** (`track_addr`, default: `True`): Track Address as SPL token
* **From Address** (`from`, default: \`\`): Filter by source address. Empty to ignore
* **To Address** (`to`, default: \`\`): Filter by destination address. Empty to ignore
* **Description** (`desc`, default: `{action} {dir} {amount} {sym}`): Description Pattern
* **Severity** (`severity`, default: `-1`): Severity See [common configuration](/common-configurations#severity).

<Note>
  Supported networks: solana.
</Note>


# Transaction Monitor
Source: https://docs.extractor.live/detectors/TxSol/DetectorTxSol

Match Solana transactions using ordered `conditions` records.

Match Solana transactions using ordered `conditions` records.

## Functionality

* Add one or more rows under **`conditions`**. Each row has three keys:

* **`field`**: which part of the transaction to test (`error`, `status`, `signer`, `accounts`, `fee`, `consumed`, `version`, `logs`).

* **`condition`**: the rule for that field (regex, comparison, exact value, or comma-separated accounts — see other FAQ entries).

* **`op`**: `OR` or `AND` — how this row combines with the running result from **previous** rows (left → right). The **first** row only seeds the accumulator; its `op` is ignored.

A row is skipped if `condition` is blank after trim. If `conditions` is empty, the detector does nothing.

* \| `field` | `condition` means |
  \| --- | --- |
  \| `error` | Must be a **valid** regex (optional leading `!` for negative). When `tx.err` is set, the pattern runs on it; when there is **no** error, only a **negative** regex matches (metadata value `null`). Invalid regex never matches. |
  \| `status` | If the string compiles as a regex (optional `!`), it is applied to `tx.sta`; if compilation **fails**, the whole string is compared to `tx.sta` with case-insensitive equality. |
  \| `signer` | Case-insensitive equality of `condition` to the **first** account key (fee payer). |
  \| `accounts` | Comma-separated addresses; match if **any** appears among message account keys (case-insensitive). |
  \| `fee` | Numeric comparison on `tx.fee` (e.g. `> 100000`, `== 5000`). |
  \| `consumed` | Numeric comparison on `tx.cost` (compute units consumed). |
  \| `version` | Exact match to `tx.ver`, or treat empty `ver` as `legacy` and match that. |
  \| `logs` | Valid regex on each log line; **any** line may satisfy. Invalid regex never matches. |
* **error** and **logs** use normal regex rules; prefix with **`!`** for a negative regex (match when the pattern does **not** match).

**status**: you can use a plain string (e.g. `Ok`) or a regex (e.g. `InstructionError`). If the string is not a valid regex, it is compared as exact text (case-insensitive).

Examples:

* `error` + `.*6001.*` — custom program error in `tx.err`.

* `error` + `!Success` — when you intend regex semantics on the error string (not the same as “successful tx” unless `tx.err` contains `Success`).

* `status` + `Ok` — successful transaction status.

* Use comparison operators on numeric fields:

* `>100000`, `<5000`, `>=10000`, `<=50000`

* `==5000` or `=5000`

* `!=0`

Whitespace around the operator and number is allowed.

* For **`logs`**, the regex is tested against **each** log line; one hit is enough. Examples: `Program.*failed`, `Error:.*`, `Program.*invoke`.

* When a transaction matches, metadata typically includes:

* **`conditions`**: comma-separated list of **field** names that matched.

* **`err`**, **`status`**, **`signer`**, **`accounts`**, **`fee`**, **`consumed`**, **`version`**, **`logs`**: values for rows that matched (each key appears only if that field matched).

* **`desc`**: from the config template.

The transaction signature is on the event’s transaction object (`tx.sig`), not necessarily in metadata.

## Configuration

* **Conditions** (`conditions`, default: `[{'op': 'AND', 'field': 'error', 'condition': 'InstructionError'}, {'op': 'AND', 'field': 'fee', 'condition': '>6500000'}]`): Ordered rules; each row: `field`, `condition`, `op` (see FAQ).
* **Description** (`desc`, default: `{conditions}: {error} {fee}`): Alert description template.
* **Severity** (`severity`, default: `-1`): Severity override (-1 = auto / default). See [common configuration](/common-configurations#severity).

<Note>
  Supported networks: solana.
</Note>


# Wallet
Source: https://docs.extractor.live/detectors/Wallet/DetectorWallet

Monitors changes to address balances

Monitors changes to address balances

## Functionality

* Detector monitors Address (Wallet or Contract) balances (native and tokens).

Detector checks balances on any transaction which references `Address`:

* Native transfer (from/to)
* ERC20 transfer (from/to)
* Transaction Events which has `Address` in its fields

If ERC-20 token is added to conditions, it will generate Alerts on conditon match.

Detector will generate **INFO** events on any token balance changes unless history tracking is disabled

* List of ERC-20 token addresses to monitor for conditions.

Use network name (e.g. `ethereum`) in **address** field for Native token condition

* Threshold condition for Alert.
  Condition is for value / dec (after division)
  E.g. for `WETH`: **>1.5** means **>1.5 WETH**
  Refer to documentation for supported formats (e.g. `>100.0`)

* Start block (used only for replays). Leave empty to track from `latest` block.

This option is used only by `Admins` for replays and will have no effect for real-time on-chain streams

* Track all Balance changes (not only conditional).

It will generate `Info` Events for any tokens balances

## Configuration

* **Tokens** (`tokens`, default: `[{'symbol': 'USDT', 'address': '0xdAC17F958D2ee523a2206206994597C13D831ec7', 'decimals': 6, 'condition': '<10000'}, {'symbol': 'USDC', 'address': '0xA0b86991c6218b36c1d19D4a2e9Eb0cE3606eB48', 'decimals': 6, 'condition': '<10000'}, {'symbol': 'WETH', 'address': '0xC02aaA39b223FE8D0A0e5C4F27eAD9083C756Cc2', 'decimals': 18, 'condition': '<10'}, {'symbol': 'ETH', 'address': 'ethereum', 'decimals': 18, 'condition': '<10'}, {'symbol': 'WETH', 'address': '0xC02aaA39b223FE8D0A0e5C4F27eAD9083C756Cc2', 'decimals': 18, 'condition': '<10'}]`): Tokens conditions
* **Description** (`desc`, default: `{action}`): Description Pattern
* **Severity** (`severity`, default: `-1`): Severity See [common configuration](/common-configurations#severity).
* **Capture Snapshots** (`track_snap`, default: `True`): Query initial balances on start and emit a one-time snapshot (INFO) event. This also seeds the baseline used by change/percent conditions. Disable to skip the startup balance query and the snapshot event.

<Note>
  Supported networks: ethereum, polygon, ethereum\_sepolia, arbitrum, hyperevm, base.
</Note>


# Wallet
Source: https://docs.extractor.live/detectors/WalletSol/DetectorWalletSol

Monitors address balances changes (Native Balance and SLP balances)

Monitors address balances changes

(Native Balance and SLP balances)

## Functionality

* Detector monitors Address (Wallet or Contract) balances (native and tokens).

Detector checks balances on any transaction which references `Address`:

* Native transfer (from/to)
* SLP transfer (from/to)
* Transaction Events which has `Address` in its fields

If Token is added to conditions, it will generate Alerts on conditon match.

* List of SLP token addresses to monitor for conditions.
  Enter `*` in **Address** field to monitor balance changes of every token.

Use network name (e.g. `solana`) in **Address** field for Native token condition

* Threshold condition to generate Alert. Refert to [Documantion](https://docs.extractor.live/common-configurations#condition-threshold) for `Condition` syntax
* Description pattern
* When enabled (default), detector queries current balances via Solana RPC API when it starts. This establishes the baseline for threshold conditions.

If disabled, thresholds start at 0, which means first transaction will likely trigger alerts.

* When enabled, detector generates events for every balance change, even if threshold condition is not crossed.

Useful for complete transaction history tracking. Default is disabled (only threshold crossings generate alerts).

## Configuration

* **Tokens** (`tokens`, default: `[{'symbol': 'SOL', 'address': 'solana', 'decimals': 9, 'condition': '>100'}, {'symbol': 'USDC', 'address': 'EPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1v', 'decimals': 6, 'condition': '> 10000'}, {'symbol': 'USDT', 'address': 'Es9vMFrzaCERmJfrF4H2FYD4KCoNkY11McCe8BenwNYB', 'decimals': 6, 'condition': '> 10000'}]`): Tokens conditions
* **Track Initial Snapshot** (`track_snap`, default: `True`): Query initial balances via RPC on detector start to establish baseline. If disabled, thresholds start at 0.
* **Track All Changes** (`track_all`, default: `False`): Track all balance changes, not just threshold crossings. Useful for complete transaction history.
* **Description** (`desc`, default: `{action}`): Description Pattern
* **Severity** (`severity`, default: `-1`): Severity See [common configuration](/common-configurations#severity).

<Note>
  Supported networks: solana.
</Note>


# Aave Monitor
Source: https://docs.extractor.live/financial-monitoring/detectors/aave-monitor

Detector monitor Aave Pools and Borrower Health If `address` is Aave Pool address, Detector will monitor `TVL` If `address` is not a Pool, Detector will monitor health factor of an address

Detector monitor Aave Pools and Borrower Health

If `address` is Aave Pool address, Detector will monitor `TVL`

If `address` is not a Pool, Detector will monitor health factor of an address

## Functionality

* Borrowing Health threshold. (Ex: **\<1.9**).

* TVL threshold in USD (Ex: **>250000000.0**)

* Cron interval to query TVL (refer to Documenation for cron syntax)

## Configuration

* **Health** (`health`, default: `<1.5`): Health threshold
* **TVL** (`tvl`, default: `>1000000000`): TVL threshold in USD
* **Cron** (`cron`, default: `10 min`): Interval to query TVL See [common configuration](/common-configurations#cron).
* **TVL source** (`tvl_method`, default: `contract`): TVL source method (contract,api)
* **Severity** (`severity`, default: `-1`): Severity See [common configuration](/common-configurations#severity).

<Note>
  Supported networks: ethereum.
</Note>


# Aster DEX Monitor
Source: https://docs.extractor.live/financial-monitoring/detectors/asterdex-monitor

Monitors Asterdex DEX for portfolio value changes and market price drops. Supports portfolio monitoring (requires API key), market monitoring (public data), or both.

Monitors Asterdex DEX for portfolio value changes and market price drops. Supports portfolio monitoring (requires API key), market monitoring (public data), or both.

## Functionality

* A monitoring service that tracks portfolio values and market prices on Aster DEX, alerting when thresholds are breached.
* Two modes: 'portfolio' (monitors account balance value) or 'market' (monitors price changes). To monitor both, create two separate detector instances with different modes.
* The monitor generates events for: portfolio value falling below threshold, significant price drops in monitored assets, and API connection errors.
* API keys are required for 'portfolio' mode. Market monitoring only uses public endpoints and doesn't require authentication.
* The detector runs on a configurable interval (default: 600 seconds / 10 minutes). You can adjust the check\_interval parameter to customize the monitoring frequency. Each check evaluates all configured conditions for portfolio thresholds and/or price drops depending on the monitoring mode. Minimum recommended: 60 seconds to avoid API rate limits.
* # SUPPORTED SYNTAX

## 1. BASIC COMPARISON OPERATORS

| Syntax | Meaning |
| - | - |
| `= value` | equals value (exact match) |
| `!= value` | not equals value (exact match) |

## 2. ABSOLUTE VALUE HANDLING

| Syntax | Meaning |
| - | - |
| `> 10` | `v > 10` **OR** `v < -10` (absolute value handling) |
| `< 25` | `\|v\| < 25` |
| `>= 35` | `\|v\| >= 35` |
| `<= 50` | `\|v\| <= 50` |

## 3. EXPLICIT SIGN HANDLING (no absolute value)

| Syntax | Meaning |
| - | - |
| `> +10` | `v > 10` (exact value, no absolute handling) |
| `> -15` | `v > -15` (exact value, no absolute handling) |
| `< +30` | `v < 30` (exact value, no absolute handling) |
| `< -20` | `v < -20` (exact value, no absolute handling) |

## 3.5. ONCE OPERATORS (edge detection – trigger only when condition transitions from false to true)

| Syntax | Meaning |
| - | - |
| `>> 10` | `v > 10` (triggers only once when condition becomes true, then false on subsequent evaluations) |
| `<< 25` | `v < 25` (triggers only once when condition becomes true, then false on subsequent evaluations) |
| `>> ++100` | increase > 100 (triggers only once when the increase condition becomes true) |
| `<< --50` | decrease > 50 (triggers only once when the decrease condition becomes true) |
| `>> 25%` | percentage change > 25% (triggers only once when condition becomes true) |
| `<< 10%` | percentage change \< 10% (triggers only once when condition becomes true) |

> **Note:**
>
> * These operators return `true` only when the condition transitions from false → true (edge detection).
> * Once true, subsequent evaluations return false even if the condition remains true.
> * Useful for detecting **threshold crossings** or **one-time events**.

## 4. PERCENTAGE OPERATIONS

| Syntax | Meaning |
| - | - |
| `> 25%` | percentage change > 25% (absolute value handling) |
| `< 10%` | percentage change \< 10% (absolute value handling) |
| `>= 50%` | percentage change >= 50% (absolute value handling) |
| `<= 75%` | percentage change \<= 75% (absolute value handling) |
| `= 100%` | percentage change = 100% (exact match) |
| `!= 200%` | percentage change != 200% (exact match) |

**Formula:** `(v - v₀) / v₀ * 100`

Examples:

* `v₀ = 1000`, `v = 700` → **-30%** (decreased by 30%)
* `v₀ = 1000`, `v = 1300` → **30%** (increased by 30%)
* `v₀ = 100`, `v = 100` → **0%** (no change)

## 5. DELTA OPERATIONS (change from previous value)

| Syntax | Meaning |
| - | - |
| `> ++100` | increase > 100 (absolute change) |
| `< --50` | decrease > 50 (magnitude of decrease) |
| `>= ++30` | increase >= 30 (absolute change) |
| `<= --25` | decrease >= 25 (magnitude of decrease) |
| `= ++20` | increase = 20 (exact change) |
| `!= ++40` | increase != 40 (exact change) |

## 6. PERCENTAGE DELTA OPERATIONS

| Syntax | Meaning |
| - | - |
| `> ++25%` | increase of percentage change > 25% |
| `< --10%` | decrease of percentage change > 10% |
| `>= ++50%` | increase of percentage change >= 50% |
| `<= --30%` | decrease of percentage change >= 30% |
| `= ++100%` | increase of percentage change = 100% |
| `!= ++200%` | increase of percentage change != 200% |

## 7. SPACES SUPPORT

| Syntax | Meaning |
| - | - |
| `> ++ 100` | increase > 100 (spaces ignored) |
| `<= -- 25` | decrease >= 25 (spaces ignored) |
| `= ++ 30.0 %` | increase = 30% (spaces ignored) |

## NOTES

* `=` and `!=` always use **exact value matching**

* `>`, `<`, `>=`, `<=` respect **absolute value handling**

* `>>`, `<<` (once operators) trigger only on **false → true** transitions

* `++`, `--` (delta operations) work with all comparison operators (including once operators)

* Percentage operations are compatible with all comparison operators

* **Spaces are ignored** during parsing

* The `abs` parameter is automatically detected:
  * `+` / `-` prefixes **disable** absolute value handling

* Once operators trigger only when a condition transitions from false to true (edge detection). For example, '>> 5%' triggers when portfolio change exceeds 5%, but won't trigger again until the change drops below 5% and then exceeds it again. This prevents repeated alerts for the same event. Use > instead of >> if you want alerts every check while the condition is true.

* Use the 'Mock Account Data' field to provide a JSON string with fake balance data. When set, the detector skips the /api/v1/account API call and uses your mock data instead. Price data is still fetched from real public endpoints. Format: `{"balances": [{"asset": "BTC", "free": "100", "locked": "0"}]}`

## Configuration

* **API Key (Portfolio mode)** (`api_key`, default: `None`): Asterex API key for authentication
* **API Secret (Portfolio mode)** (`api_secret`, default: `None`): Asterex API secret for HMAC SHA256 signature
* **Check Interval (seconds)** (`check_interval`, default: `600`): Time interval between monitoring checks in seconds. Default is 600 seconds (10 minutes). Minimum recommended: 60 seconds to avoid API rate limits.
* **Monitoring Mode** (`monitoring_mode`, default: `portfolio`): Monitoring mode: 'portfolio' or 'market'
* **Monitored Assets - Market mode** (`monitored_assets`, default: `[{'asset': 'BTC', 'condition': '>> 10'}, {'asset': 'BNB', 'condition': '> 5%'}]`): List of assets to monitor with flexible conditions (only used in market mode). Each asset has its own condition. Not needed for portfolio mode.
* **Mock Account Data (Testing Only) - Portfolio mode** (`mock_account_data`, default: `None`): Optional JSON string with mock account balance data for testing. When provided, skips the /api/v1/account API call. Format: `{"balances": [{"asset": "BTC", "free": "100", "locked": "0"}]}`
* **Portfolio Condition - Portfolio mode** (`portfolio_condition`, default: `>> 5%`): Flexible condition using Scala SDK syntax. Examples: >> 5% (alert once when portfolio drops >5%), > 10% (alert every time portfolio changes >10%), \< 10000000 (alert when below $10M), >> ++1000000 (alert once when portfolio increases >$1M)

<Note>
  Supported networks: evm.
</Note>


# Balance Monitor
Source: https://docs.extractor.live/financial-monitoring/detectors/balance-monitor

The `BalanceMonitor` is a transaction detector that monitors the balance of accounts or contracts (native token and ERC20 tokens) on a blockchain network. It checks if the balance falls below a specified threshold and sends notifications when this occurs.

The `BalanceMonitor` is a transaction detector that monitors the balance of accounts or contracts (native token and ERC20 tokens) on a blockchain network. It checks if the balance falls below a specified threshold and sends notifications when this occurs.

## Functionality

* The `BalanceMonitor` is a transaction detector that monitors the balance of accounts or contracts (native token and ERC20 tokens) on a blockchain network. It checks if the balance falls below a specified threshold and sends notifications when this occurs. The monitor automatically handles configuration changes and incoming transactions. This tool is especially useful for applications where maintaining a minimum balance is critical, such as payment systems, staking wallets, or operational accounts
* The Balance Monitor has the following key features:
* Monitor the balance of accounts or contracts (native token and ERC20 tokens)
* Set a balance threshold for native token and ERC20 tokens
* Set a severity level for notifications
* Automatically handle configuration changes and incoming transactions
* Send notifications when the balance falls below the specified threshold
* The Balance Monitor supports the following address types:
* Native Token
* ERC20 Token
* The following parameters are available for the native token:
* Balance Threshold: The minimum balance required for the account or contract
* Decimals: The number of decimal for the native token
* The following parameters are available for the ERC20 token:
* Address: The ERC20 token address
* Balance Threshold: The minimum balance required for the ERC20 token
* Decimals: The number of decimal for the ERC20 token
* Symbol: The symbol of the ERC20 token
* The `BalanceMonitor` operates in real-time, actively monitoring transactions and blockchain events to ensure timely detection of balance changes. It processes native token transfers as well as ERC20 token transactions.
* Native Token, for transactions involving native tokens:
* The monitor checks the current balance of the relevant address.
* If the balance falls below the configured threshold, a notification is triggered.
  ERC20 Token, for detected TRANSFER events of ERC20 tokens: - The monitor examines the from and to addresses to check if they are in the monitoring list.
* If an address is found, the monitor queries the balance of the specific ERC20 token for that address.
* If the token balance is below the threshold, a notification is sent.

## Configuration

* **Threshold** (`balance_threshold`, default: `200000000000000000`): Balance Threshold
* **Decimals** (`decimals`, default: `18`): Decimals
* **ERC20 Tokens** (`erc20_tokens`, default: `None`): ERC20 Token
* **Severity** (`severity`, default: `-1.0`): Severity See [common configuration](/common-configurations#severity).

<Note>
  Supported networks: evm.
</Note>


# Contract Call
Source: https://docs.extractor.live/financial-monitoring/detectors/contract-call

Execute calls to contract function (not transaction), extracts results and check conditions

Execute calls to contract function (not transaction), extracts results and check conditions

## Functionality

* Function to execute.
  It must be a full signature in the [foundry cast](https://getfoundry.sh/cast/reference/cast) format

(e.g. `balanceOf(address)(uint256)`)

* Parameters to pass to the function.
  Parameters can be separated with spaces or new lines.

Tuples must be enclosed in `()`.

Arrays must be enclosed in `[]`

Strings must be enclosed in `""`

Refer to [cast](https://getfoundry.sh/cast/reference/cast) documentation for syntax

* Sender address (optional). If not specified, the contract address will be used as sender.
* Cron interval to execute call (for `cron` **When** mode). Refer to [Cron](https://docs.extractor.live/common-configurations#cron) for more details
* Scripts to execute

Scripts are executed in the order they are specified. Refer to [Scripts](https://docs.extractor.live/common-configurations#condition-threshold) for more details.

Scripts execution result will be in `result` meta field.

* When to execute script:

`block` - every block
`cron` - at cron intervals

* Desciption field pattern. Metadata fields from Alert can be used as Substitutions and must be enclosed in `{}`

Example: `{func}: {result}`

* Generate Alerts on Errors (in Contract Call or Evaluation Script)
* Alert on every Error. If `unchecked`, only new unique Errors will be alerted and duplicates will be omitted

## Configuration

* **When** (`when`, default: `cron`): When to call the contract
* **Cron** (`cron`, default: `10 min`): Interval to execute See [common configuration](/common-configurations#cron).
* **Function** (`func`, default: `None`): Function signature (foundry format)
* **Parameters** (`params`, default: \`\`): Function parameters
* **Sender** (`sender`, default: \`\`): Sender address (optional)
* **Scripts** (`script`, default: `[]`): Scripts to execute
* **Track Errors** (`track_err`, default: `True`): Track Call/Script error
* **Track Errors (always)** (`err_always`, default: `False`): Always Alert on Error
* **Description** (`desc`, default: `{func}: {result}{err}`): Description Pattern
* **Severity** (`severity`, default: `-1`): Severity See [common configuration](/common-configurations#severity).

<Note>
  Supported networks: ethereum, ethereum\_sepolia, hyperevm, base.
</Note>


# Network Monitor
Source: https://docs.extractor.live/financial-monitoring/detectors/network-monitor

Monitors Remote host connectivity / availability with periodic requests

Monitors Remote host connectivity / availability with periodic requests

## Functionality

* Detector sends `type` requests and optionally parses response within specified timeout

* Url (Address) to monitor

* Request type: `GET`, `POST`, `PUT`, `HEAD`, `OPTIONS`, `PING`, `TCP`.

* PING: checks if host is reachable

* TCP: checks if port is reachable

* Cron interval. Refer to [Cron](https://docs.extractor.live/common-configurations#cron) for more details

* Scripts to execute to process response body.

Scripts are executed in the order they are specified. Refer to [Scripts](https://docs.extractor.live/common-configurations#condition-threshold) for more details.

Scripts execution result will be in `result` meta field.

* Request Body (applicable for `HTTP` requests)
* Request Headers
* Max redirects for HTTP request
* Optional `Authorization:` header. This header is added to the list of Headers
* Latency threshold (condition) in milliseconds to receive response.

Refer to [https://docs.extractor.live/](https://docs.extractor.live/) for threshold expression syntax).

Example: `>1000`

* Score condition if Scripts return score. If condition is not matched, Alert is not generated.

If `score` is empty, score is not verified. Refer to [Score](https://docs.extractor.live/common-configurations#condition-threshold) for more details

* Generate Alerts on Errors (in Script execution)
* Alert on every Error. If `unchecked`, only new unique Errors will be alerted and duplicates will be omitted
* Description template for the Alert description. Can use any meta field as placeholder (e.g. `{result}`)

## Configuration

* **Cron** (`cron`, default: `10 min`): Cron expression See [common configuration](/common-configurations#cron).
* **Url** (`url`, default: \`\`): Url to monitor
* **Request type** (`type`, default: `GET`): Request type
* **Request Body** (`body`, default: \`\`): Request Body
* **Headers** (`headers`, default: `None`): Request Headers
* **Max redirects** (`redirects`, default: `2`): Max redirects
* **Authorization header** (`auth`, default: \`\`): Authorization header
* **Scripts** (`script`, default: `[]`): Scripts to execute
* **Track Successful** (`track_ok`, default: `True`): Track Successful Responses as Alerts
* **Track Errors** (`track_err`, default: `True`): Track Errors as Alerts
* **Track Error (always)** (`err_always`, default: `True`): Always Alert on Error
* **Score** (`score`, default: \`\`): Score condition
* **Latency (msec)** (`latency`, default: `>1000`): Response latency threshold (msec)
* **Description** (`desc`, default: `{status} {err}`): Description
* **Severity** (`severity`, default: `-1`): Severity See [common configuration](/common-configurations#severity).

<Note>
  No specific network configuration required (Any network).
</Note>


# Price Monitor
Source: https://docs.extractor.live/financial-monitoring/detectors/price-monitor

Monitors Price changes of the Contract. Contract must be a Token contract (ERC-20 like)

Monitors Price changes of the Contract.

Contract must be a Token contract (ERC-20 like)

## Functionality

* Cron expression can be specified in milliseconds, Quartz expression syntax or seconds/minutes/hours prefix (e.g.  `10 minutes`).

There is an internal throttling with 60 seconds interval, so intervals should be >1 minute

Cron expression is Quartz syntax (ex:  "0 0/10 \* 1/1 \* ? \*" == every 10 minutes)

* Price value threshold for triggering Alerts. (Ex: >5% for percentage or \<200 for absolute values)

Refer to the [documentation](https://docs.extractor.live/) for supported formats

* Supply your own Coingecko API key for faster Cron interval (default minimum is 10 min)
* When to query price:

`cron` - On Cron interval

`block` - On every new block(Useful for Oracle source)

* Where to query price:

`oracle` - On-chain Feed (Chainlink Oracle format)

`coingecko` - Coingecko Feed

* Currency of the price. Default is `usd`. (Refer to CoinGecko documentation for supported currencies)

**NOTE**: Currently supported only for `coingecko` feed.

`oracle` feed requires adding Chainlink Oracle Contracts in configuration

## Configuration

* **Cron expression** (`cron`, default: `10 min`): Cron expression in Quartz format (or milliseconds) See [common configuration](/common-configurations#cron).
* **Price Threshold** (`threshold`, default: \`\`): Price threshold in USD See [common configuration](/common-configurations#condition).
* **API Key** (`api_key`, default: `None`): Custom API Key
* **When** (`when`, default: `cron`): When to query price
* **Source** (`source`, default: `coingecko`): Price feed source
* **Currency** (`currency`, default: `usd`): Price currency
* **Severity** (`severity`, default: `-1`): Severity See [common configuration](/common-configurations#severity).

<Note>
  Supported networks: evm.
</Note>


# Safe Multisig Monitor
Source: https://docs.extractor.live/financial-monitoring/detectors/safe-multisig-monitor

The Safe Multisig Monitor is a detector that monitors the signers of a Safe Multisig contract and alerts if a signer signes a tx data that differs from the other signers.

The Safe Multisig Monitor is a detector that monitors the signers of a Safe Multisig contract and alerts if a signer signes a tx data that differs from the other signers.

## Functionality

* This is a monitoring service that tracks activities related to a Safe Multisig contract, including signer changes, transaction executions, and confirmation submissions.
* The monitor continuously fetches data from the Safe Multisig contract and triggers events when:
* A new signer is detected.
* A transaction is executed after reaching the required threshold of confirmations.
* A signer submits a confirmation for a pending transaction.
* A submitted Safe transaction hash does not match the expected computed hash.
* A transaction signature does not match the expected signer.
* The monitor generates three types of events:
* Safe Multisig Signer - Triggered when the list of signers is retrieved.
* Safe Multisig Transaction - Triggered when a transaction is fully confirmed and executed.
* Safe Multisig Confirmation - Triggered when a signer submits a confirmation for a pending transaction.
* Safe Multisig Safe Tx Hash Mismatch - Triggered when a submitted Safe transaction hash does not match the expected computed hash.
* Safe Multisig Signature Mismatch - Triggered when a submitted signature does not match the expected signer.
* Safe Multisig Simulation - Triggered when a new transaction is created on Safe.
* * It computes the Safe transaction hash and compares it to the submitted hash to ensure it has not been tampered with.
* It validates the signatures provided for each transaction to ensure authenticity.
* It logs detected mismatches and alerts users when discrepancies occur.

## Configuration

* **Severity** (`severity`, default: `0.5`): Severity See [common configuration](/common-configurations#severity).

<Note>
  Supported networks: ethereum, bsc, polygon, optimism, ethereum\_sepolia, avalanche, base, arbitrum.
</Note>


# Total Supply Monitor
Source: https://docs.extractor.live/financial-monitoring/detectors/total-supply-monitor

The Total Supply Monitor is a daily monitoring tool designed to track the total supply of a token. It will send alerts if the total supply of the token exceeds the expected value. This monitor offers users insights into token distribution trends and ensuring compliance with time-based reporting needs, helping maintain consistency and transparency in token supply.

The Total Supply Monitor is a daily monitoring tool designed to track the total supply of a token. It will send alerts if the total supply of the token exceeds the expected value. This monitor offers users insights into token distribution trends and ensuring compliance with time-based reporting needs, helping maintain consistency and transparency in token supply.

## Functionality

* The Expected value fields require whole token values, not raw units. This input is compared against the on-chain supply, normalized using the configured Decimals. Ensure the Decimals value is accurate, as incorrect settings will distort the calculated supply magnitude and prevent alerts.

## Configuration

* **Expected Total Supply** (`expected_total_supply`, default: `None`): Expected Total Supply
* **Expected Total Issued Tokens** (`expected_total_issued`, default: `None`): Expected Issued Tokens
* **Token decimals value** (`decimals`, default: `18`): Token decimals value
* **Severity** (`severity`, default: `-1`): Severity See [common configuration](/common-configurations#severity).

<Note>
  Supported networks: evm.
</Note>


# Total Supply Monitor By Allocations
Source: https://docs.extractor.live/financial-monitoring/detectors/total-supply-monitor-by-allocations

The Total Supply Monitor by Allocations is a detector that monitors the total supply of a token by allocations. It checks the total supply of a token by comparing the expected total supply with the actual total supply.

The Total Supply Monitor by Allocations is a detector that monitors the total supply of a token by allocations. It checks the total supply of a token by comparing the expected total supply with the actual total supply.

## Functionality

* See configuration parameters below.

## Configuration

* **Token decimals value** (`decimals`, default: `18`): Token decimals value
* **Severity** (`severity`, default: `-1`): Severity See [common configuration](/common-configurations#severity).

<Note>
  Supported networks: evm.
</Note>


# Transfer Monitor
Source: https://docs.extractor.live/financial-monitoring/detectors/transfer-monitor

The Transfer Monitor tracks transfers via monitored contracts, to/from addresses in transaction logs and notify the Extractor if amount exceed predefined threshold.

The Transfer Monitor tracks transfers via monitored contracts, to/from addresses in transaction logs and notify the Extractor if amount exceed predefined threshold.

## Functionality

* To define a threshold, specify the transfer amount that will trigger an alert.  This should be in integer format, for example, 1000000

## Configuration

* **Severity** (`severity`, default: `-1.0`): Severity See [common configuration](/common-configurations#severity).
* **Threshold** (`threshold`, default: `None`): Threshold Amount See [common configuration](/common-configurations#condition).

<Note>
  Supported networks: evm.
</Note>


# Transfers
Source: https://docs.extractor.live/financial-monitoring/detectors/transfers-detector

Detector monitors asset transfers (both native and tokens) to and from Monitored Address Detector can be used to detect anomolous, frequent, whale transfers. Detector can track `monitored` Address as ERC-20 for Token transfers in addition to `from` and `to` condition.

Detector monitors asset transfers (both native and tokens) to and from Monitored Address

Detector can be used to detect anomolous, frequent, whale transfers.

Detector can track `monitored` Address as ERC-20 for Token transfers in addition to `from` and `to` condition.

## Functionality

* Detector monitors Token transfers (both ERC-20 and Native token supported) for value amount
* List of token addresses to monitor.

For native transfer monitoring, use native token symbol in `address` fields (e.g. `ETH` for Ethereum, `BNB` for BSC network)

* The **Threshold** value is interpreted based on the **Decimals** setting.
  If **Decimals** matches the token's standard precision (e.g. `6` for **USDC**), the input represents *whole tokens* (e.g. `50` equals **50 USDC**).
  If **Decimals** is set to `0`, the input is treated as the smallest unit (*wei*), meaning `50` equals **0.000050 USDC**.

Refer to the documentation for supported formats.

* Track Monitored address in `to`
* Track Monitoed Address in `from`
* Track `frequent` transfers. Parameter specified transfers number threshold within `cron` interval

Value `0` means no tracking

* Track Monitored Address as ERC-20 token for this Token transfers
* Optional `From` address filter.

NOTE: It it is not correlated with `Track From`

* Optional `To` address filter.

NOTE: It it is not correlated with `Track To`

## Configuration

* **Tokens** (`tokens`, default: `[{'symbol': 'USDT', 'address': '0xdAC17F958D2ee523a2206206994597C13D831ec7', 'decimals': 6, 'threshold': '>10000000'}, {'symbol': 'USDC', 'address': '0xA0b86991c6218b36c1d19D4a2e9Eb0cE3606eB48', 'decimals': 6, 'threshold': '>10000000'}, {'symbol': 'WETH', 'address': '0xC02aaA39b223FE8D0A0e5C4F27eAD9083C756Cc2', 'decimals': 18, 'threshold': '>10000'}, {'symbol': 'ETH', 'address': 'ethereum', 'decimals': 18, 'threshold': '>10000'}, {'symbol': 'BNB', 'address': 'BNB', 'decimals': 18, 'threshold': '>100000'}]`): Additional tokens to monitor
* **Track From** (`track_from`, default: `True`): Track From Address
* **Track To** (`track_to`, default: `True`): Track To Address
* **From** (`from`, default: \`\`): From address filter
* **To** (`to`, default: \`\`): To address filter
* **Track Address** (`track_addr`, default: `True`): Track Address as ERC-20 token
* **Description** (`desc`, default: `{action} {dir} {amount} {sym}`): Desription pattern
* **Severity** (`severity`, default: `-1`): Severity See [common configuration](/common-configurations#severity).

<Note>
  Supported networks: zeta, ethereum, bsc, polygon, ethereum\_sepolia, polygon\_amoy, arbitrum, base\_sepolia, hyperevm, base.
</Note>


# TVL Monitor
Source: https://docs.extractor.live/financial-monitoring/detectors/tvl-monitor

TVL Monitor tracks liquidity changes for ERC20 tokens & contracts by referencing your pre-configured thresholds. If the balance of a particular asset declined below a threshold, Extractor will notify your team.

TVL Monitor tracks liquidity changes for ERC20 tokens & contracts by referencing your pre-configured thresholds. If the balance of a particular asset declined below a threshold, Extractor will notify your team.

## Functionality

* You can monitor two types of assets for TVL monitoring: ERC-20 tokens and Native coin of the network
* To define a ERC-20 token for monitoring you need to specify its address and threshold for Value Locked for that particular asset
* To include Native coin holdings for TVL monitoring you need to click on "Monitoring Native Token" checkbox and to provide a threshold as well.
* To define a threshold, specify the absolute value or the percentage with '%' sign
* No, in the current version, each threshold is set regarding particular asset (ERC-20 token of Native coin)
* No, you will be notified only about balances change of the assets you have specified for the monitoring.

## Configuration

* **Monitoring Tokens** (`tokens`, default: `None`): Monitoring Tokens
* **Native Token** (`native_token_status`, default: `True`): Monitoring Native Token
* **Native Token Threshold** (`native_token_threshold`, default: `1%`): Native Token Threshold, the value can be entered as absolute value or as percentage (with '%' sign)
* **Severity** (`severity`, default: `0.5`): Event Severity See [common configuration](/common-configurations#severity).

<Note>
  Supported networks: evm.
</Note>


# Financial Monitoring
Source: https://docs.extractor.live/financial-monitoring/intro

Enhance your project with Hacken Extractor financial monitors and detectors that track on-chain value, balances, reserves, and market conditions.

Financial Monitoring provides detectors that watch token prices, balances, total value locked, circulating supply, and DEX activity. Configure thresholds and conditions to receive alerts the moment key financial metrics move outside expected ranges.

<CardGroup>
  <Card title="Aave Monitor" icon="building-columns" href="/financial-monitoring/detectors/aave-monitor">Track Aave protocol positions and liquidity pool metrics.</Card>
  <Card title="Aster DEX Monitor" icon="chart-line" href="/financial-monitoring/detectors/asterdex-monitor">Monitor portfolio value and asset prices on Aster DEX.</Card>
  <Card title="Balance Monitor" icon="wallet" href="/financial-monitoring/detectors/balance-monitor">Alert when native coin or ERC-20 balances fall below threshold.</Card>
  <Card title="Price Monitor" icon="dollar-sign" href="/financial-monitoring/detectors/price-monitor">Alert on token price movements beyond configured thresholds.</Card>
  <Card title="Safe Multisig Monitor" icon="users" href="/financial-monitoring/detectors/safe-multisig-monitor">Track Safe multisig proposals and executions.</Card>
  <Card title="Total Supply Monitor" icon="coins" href="/financial-monitoring/detectors/total-supply-monitor">Alert on unexpected changes to token total supply.</Card>
  <Card title="TVL Monitor" icon="lock" href="/financial-monitoring/detectors/tvl-monitor">Alert when total value locked drops significantly.</Card>
</CardGroup>


# Getting Started
Source: https://docs.extractor.live/index

Get started with Hacken Extractor — real-time on-chain security monitoring that safeguards smart contracts, wallets, and DeFi protocols from hacks.

## About

Hacken Extractor is an advanced on-chain security monitoring system that provides real-time monitoring of your addresses and alerts you of any suspicious activity to prevent potential hacks. With Hacken Extractor, you can rest assured that your addresses are secure, and take immediate action if any security threats are detected.

<CardGroup>
  <Card title="Security Monitoring" icon="shield" href="/security-monitoring/intro">
    Detect AML flags, address poisoning, block anomalies, and more.
  </Card>

  <Card title="Advanced Monitoring" icon="sliders" href="/advanced-monitoring/intro">
    Build custom triggers for ERC-20 transfers, function calls, and events.
  </Card>

  <Card title="Compliance Monitoring" icon="scale-balanced" href="/compliance-monitoring/intro">
    Track price, TVL, supply, and regulatory risk indicators.
  </Card>

  <Card title="API Reference" icon="square-terminal" href="/api-reference/introduction">
    Manage projects, contracts, and alerts programmatically.
  </Card>
</CardGroup>

## How does it work?

Hacken Extractor continuously monitors your addresses and checks every transaction against it by the triggers and detectors.

<AccordionGroup>
  <Accordion title="Detectors" icon="magnifying-glass">
    The purpose of the attack detector is to recognize suspicious activity and collect suspicious accounts and contracts to warn against interactions with those addresses.
  </Accordion>

  <Accordion title="Triggers" icon="bolt">
    A trigger is a specific condition or set of conditions that are monitored. When these conditions are met, the monitoring system will alert you in real time, providing complete monitoring and protection for your smart contracts. You have full control over the triggers and can customize them to meet your specific security needs, ensuring that the monitoring system only reacts to important events.
  </Accordion>

  <Accordion title="Actions" icon="play">
    Smart Contract Actions let you automate on-chain responses when an alert fires — for example, pausing a contract or executing a withdrawal.
  </Accordion>
</AccordionGroup>

## Quick setup

<Steps>
  <Step title="Sign up / Sign in">
    Create your account at [extractor.hacken.io](https://extractor.hacken.io).
  </Step>

  <Step title="Create a project">
    Click **Add project**, enter a name, and click **Create**.

    <img alt="Create project step 1" />

    <img alt="Create project step 2" />
  </Step>

  <Step title="Add an address">
    Click **Add entity**, enter the entity name and address, choose the network, and click **Add Entity**.

    <img alt="Add entity step 1" />

    <img alt="Add entity step 2" />

    <img alt="Entity created" />
  </Step>
</Steps>


# Cookie Policy
Source: https://docs.extractor.live/legal-documents/cookie-policy

Hacken Extractor cookie policy — how we use cookies and similar tracking technologies on our documentation and product surfaces. Updated 16 Mar 2023.

Hacken OÜ ("Hacken" or "we") welcomes you. We have created this Cookie Policy ("Cookie Policy") in the spirit of transparency, as it provides detailed information about why, how, and when we use cookies on our web application. The Cookie Policy applies to our web application, available following the link – [https://extractor.hacken.io/](https://extractor.hacken.io/) ("App"). Learn more about who we are, how you can contact us, and how we process personal data in our [Privacy Notice](/legal-documents/privacy-notice).

### Content

[**About us**](#about-us)

[**About Cookies**](#about-cookies)

[**Cookies usage**](#cookies-usage)

[**How to turn off cookies**](#how-to-turn-off-cookies)

[**Cookies we use**](#cookies-we-use)

* [Necessary cookies](#necessary-cookies)
* [Statistics cookies](#statistics-cookies)
* [Marketing cookies](#marketing-cookies)

[**Cookie Policy updating**](#cookie-policy-updating)

### About Us

| | |
| - | - |
| **Data Controller** | Hacken OÜ |
| **Address** | Harju maakond, Tallinn, Kesklinna linnaosa, Parda tn 4, 10151. |
| **Email** | [extractor@hacken.io](mailto:extractor@hacken.io) - for any issues |

### About Cookies

A cookie is a small text file that is placed on your hard drive by a web page server. Cookies contain information that a web server can later read in the domain that issued the cookie to you.

Some cookies will only be used if you use certain features or select certain preferences, and some cookies are essential to the App and will always be used.

According to EU legislation, we can store cookies on your device if they are strictly necessary for this App's operation. For all other types of cookies, we need your permission. You can change or withdraw your consent at any time from the cookies we collect.

### Cookies usage

We use cookies and other technologies to ensure everyone using the App has the best possible experience. For example, when you use our App, we may place several cookies in your browser. We use these cookies:

* to enable us to hold session information as you navigate from page to page within the App;
* to improve your experience;
* to track and analyse usage and other statistical information.

If you elect not to activate cookies or disable cookies later, you may still visit our App, but your ability to use some features or areas of those offerings may be limited.

<Info>
  Please note! We will ask for your consent if data transfer is not part of the contract.
</Info>

### How to turn off cookies

You can generally activate or later deactivate the use of cookies through a functionality built into your web browser. If you want to disable cookies, then you can find instructions for managing your browser settings at these links:

| | | | |
| :-: | :-: | :-: | :-: |
| [Internet Explorer](https://support.microsoft.com/en-us/help/17442/windows-internet-explorer-delete-manage-cookies) | [Firefox](https://support.mozilla.org/en-US/kb/cookies-information-websites-store-on-your-computer) | [Chrome](https://support.google.com/chrome/answer/95647) | [Opera](https://help.opera.com/en/latest/web-preferences/) |
| [Microsoft Edge](https://privacy.microsoft.com/en-us/windows-10-microsoft-edge-and-privacy) | [Vivaldi](https://help.vivaldi.com/article/privacy-settings/) | [Safari](https://support.apple.com/guide/safari/manage-cookies-and-website-data-sfri11471/) | [Brave](https://support.brave.com/hc/en-us/articles/360050634931-How-Do-I-Manage-Cookies-In-Brave-) |

If you want to learn more about cookies or how to control, disable, or delete them, please visit [www.allaboutcookies.org](https://allaboutcookies.org/) for detailed guidance. In addition, specific third-party advertising networks, including Google, permit users to opt out of or customise preferences associated with their Internet browsing. To learn more about this feature from Google, click [here](https://myadcenter.google.com/?sasb=true).

### Cookies we use

We use several types of cookies:

* [Necessary cookies](#necessary-cookies)
* [Statistics cookies](#statistics-cookies)
* [Marketing cookies](#marketing-cookies)

#### Necessary cookies

Necessary cookies help make an App usable by enabling basic functions like page navigation and access to secure areas of the App. The App cannot function properly without these cookies.

| Name | Purpose | Expiry |
| - | - | - |
| hjViewportId | Saves the user's screen size in order to adjust the size of images on the App. | Session |
| \_\_mp\_opt\_in\_out\_1054d23887865f53b923616c5b3b3f12 | Shows the state of the SDK instance. | Session |

#### Statistics cookies

Statistics cookies help the App owners to understand how visitors interact with Apps by collecting and reporting information anonymously.

| Name | Purpose | Expiry |
| - | - | - |
| \_ga | Registers a unique ID for the session. This is used to generate statistical data on how the visitor uses the App. | 2 years |
| *ga*# | Used by Google Analytics to collect data on the number of times a user has visited the App as well as dates for the first and most recent visit. | 2 years |
| \_gat | Used by Google Analytics to throttle request rate. | 1 day |
| \_gid | Registers a unique ID that is used to generate statistical data on how the visitor uses the App. | 1 day |
| \_hjAbsoluteSessionInProgress | This cookie is used to count how many times different visitors have visited an App – this is done by assigning the visitor an ID, so the visitor does not get registered twice. | 1 day |
| \_hjFirstSeen | This cookie is used to determine if the visitor has visited the App before, or if it is a new visitor to the App. | 1 day |
| \_hjIncludedInPageviewSample | Used to detect whether the user navigation and interactions are included in the App's data analytics. | 1 day |
| \_hjIncludedInSessionSample | Registers data on visitors' App-behaviour. This is used for internal analysis and App optimization. | 1 day |
| \_hjLocalStorageTest | | Persistent |
| \_hjRecordingLastActivity | Sets a unique ID for the session. This allows the App to obtain data on visitor behaviour for statistical purposes. | Session |
| *hjSession*# | Collects statistics on the visitor's visits to the App, such as the number of visits, average time spent on the App and what pages have been read. | 1 day |
| *hjSessionUser*# | Collects statistics on the visitor's visits to the App, such as the number of visits, average time spent on the App and what pages have been read. | 1 year |
| \_hjTLDTest | Registers statistical data on users' behaviour on the App. Used for internal analytics by the App operator. | Session |

#### Marketing cookies

Marketing cookies are used to track visitors across Apps. The intention is to display relevant and engaging ads for the individual user, making them more valuable for publishers and third-party advertisers.

| Name | Purpose | Expiry |
| - | - | - |
| **mpq*#*# | Collects data on user behaviour and interaction in order to optimise the App and make advertisement on the App more relevant. | Persistent |
| \_fbp | Used by Facebook to deliver a series of advertisement products such as real-time bidding from third-party advertisers. | 3 months |
| ads/ga-audiences | Used to detect whether the user intends to leave the page via cursor movements. This allows the App to trigger certain pop-ups to keep the user on the App or convert them to customers. | Session |
| mp\_#\_mixpanel | Used by MixPanel for analytics purposes. | 1 year |

### Cookie Policy updating

If there are any material changes to this Policy, we will notify you by posting a prominent notice on our App before the change becomes effective. We encourage you to review this page periodically for the latest information from Cookie Policy.

Your continued use of the App constitutes your agreement to be bound by such changes to the Cookie Policy. If you do not accept the terms of the Cookie Policy, your only remedy is to discontinue using and accessing the App.


# Privacy Notice
Source: https://docs.extractor.live/legal-documents/privacy-notice

Hacken Extractor privacy notice — what personal data we collect, how we use it, your rights, and contact details for data requests. Updated 16 Mar 2023.

Hacken OÜ ("Hacken" or "we") cares about your personal data and does everything possible to protect it. This Privacy Notice ("Privacy Notice") is here to help you understand what happens to your personal data when you use our web application, available by the link – [https://extractor.hacken.io/](https://extractor.hacken.io/) ("App").

### Content

[**About us**](#about-us)

[**About you**](#about-you)

[**Personal data**](#personal-data)

* [Sources of data](#sources-of-data)
* [Legal basis for processing](#legal-basis-for-processing)
* [Visitors' data](#visitors-data)
* [Beta Askers' data](#beta-askers-data)
* [Extractors' user data](#extractors-user-data)
* [Support Requesters' data](#support-requesters-data)
* [Data obtained from third parties](#data-obtained-from-third-parties)

[**Data sharing with third parties**](#data-sharing-with-third-parties)

* [Details](#details)

[**Data protection**](#data-protection)

[**Data subjects rights**](#data-subjects-rights)

[**Cookies**](#cookies)

[**Update**](#update)

### About us

| | |
| - | - |
| Data controller | Hacken OÜ |
| Address | Harju maakond, Tallinn, Kesklinna linnaosa, Parda tn 4, 10151 |
| Email | [support@hacken.io](mailto:support@hacken.io) - for any issues |

### About you

When you visit our App, you become our user ("User").

| Type of User | Description |
| - | - |
| Visitor. | The User who visits our App. |
| Beta Asker. | The User who asks Beta to try. |
| Extractor user. | The User who uses our Extractor App. |
| Support Requester. | The User who lodges a support request in Extractor App. |

### Personal data

#### Sources of data

We receive data when you visit our App and interact with it, depending on your actions on the App. We may also (although we do not necessarily do so) receive data from third parties. It depends on your settings and the features you use.

#### Legal basis for processing

To process your personal data, we rely on the following lawful basis:

* **performance of the contract** — for the processing of personal data necessary for the negotiating on, conclusion, and performance of a contract with you;
* **legitimate interest** — for the processing necessary for the development of our services and reasonable for you;
* **consent** — for additional processing for specific purposes (read more below).

#### Visitors' data

When you use our App as a Visitor, we collect some data automatically. We need technical data to operate, support, and improve the App's functionality.

| Source of data | Description | Reasons for processing | Legal basis |
| - | - | - | - |
| Necessary technical data. | Information about your visits and use of the App, including the source of the links, the time and duration of the visit, and navigation. | The smooth operation of the App. | Legitimate interest. |
| Necessary cookies. | Information that is necessary for the operation of the App. | Improving your experience using the App. | Performance of the contract. |
| Statistics cookies. | Information is used to understand how Users interact with the App by collecting and reporting information. | To monitor App performance for statistical purposes. | Consent. |
| Marketing cookies. | Marketing information used to match relevant advertising to you. | Marketing. | Consent. |

Data storage

| | |
| - | - |
| Data that is processed on the basis of a legitimate interest. | Stored for up to 3 years after the last use of the App. |
| Data is processed on the basis of your consent. | Storage periods are presented in our Cookies Policy. |

#### Beta Askers' data

| We collect data when | Description | Reasons for processing | Legal basis |
| - | - | - | - |
| You leave the request to an Extractor. | Your answers in the poll; name; email. | To conduct a survey and list you for our program's first beta trial. | Performance of the contract. |

Data storage

| | |
| - | - |
| Data that is processed on the basis of the performance of a contract. | Stored until completion of services + 3 years. |

#### Extractors' user data

| We collect data when | Description | Reasons for processing | Legal basis |
| - | - | - | - |
| You complete registration. | Password. | To protect your account. | Performance of the contract. |
| You log in. | Email; password. | To log in you. | Performance of the contract. |
| You add destinations for notifications. | Other emails; nicknames in messengers. | To add other emails or nicknames to the list of notifications. | Performance of the contract. |
| You set up a meeting to share feedback. | Name; email; your message; time zone; preferable time and date for a meeting. | Contacting us. | Performance of the contract. |
| You add the smart contract. | Smart contract address; chain. | To monitor smart contract. | Performance of the contract. |
| You select a contract type. | Contract type. | To personalise service. | Performance of the contract. |
| You create your own trigger. | Trigger name; event; severity. | To personalise service. | Performance of the contract. |
| You create your own trigger. | Notifications. | To personalise service. | Consent. |

Data storage

| | |
| - | - |
| Data that is processed on the basis of the performance of a contract. | Stored until completion of services + 3 years. |
| Data that is processed on the basis of consent. | Until withdrawn. |

#### Support Requesters' data

| Source of data | Description | Reasons for processing | Legal basis |
| - | - | - | - |
| You leave a request to support. | User ID; theme of request; your message. | To process your application. | Performance of the contract. |

Data storage

| | |
| - | - |
| Data that is processed on the basis of the performance of a contract. | Stored until completion of services + 3 years. |

#### Data obtained from third parties

Also, we can collect some data from third parties. Our partners may provide us with it. We may receive data through our other services.

The scope of the data collected, the purposes and the legal basis for the processing is determined by the respective privacy documents of our other services:

| Our services | Link to privacy documents |
| - | - |
| [Calendly](https://calendly.com/) | [Privacy Notice](https://calendly.com/privacy) |
| [HackenProof](https://hackenproof.com/) | [Privacy Notice](https://hackenproof.com/pages/policy) |
| [hVpn](https://hackenvpn.com/) | [Privacy Notice](https://hackenvpn.com/hvpn-privacy-notice.pdf) |
| [hPass](https://hackenpass.com/) | [Privacy Notice](https://hackenpass.com/privacy_notice_hpass.pdf) |
| [CER.Live](https://cer.live/) | [Privacy Notice](https://cer.live/pdf/privacy-policy.pdf) |
| [Hacken.ai](https://hacken.ai/) | [Privacy Notice](https://hacken.ai/content/hackenai_application_privacy_notice.pdf) |
| [Trust Army](https://trustarmy.com/) | [Privacy Notice](https://trustarmy.com/Privacy%20Notice%20-%20Trust%20Army.pdf) |

**Please note**: we can get data from third parties, but we won't necessarily get it. It all depends on your settings and the features you use. For example, we can receive data if you communicate with us through these third parties.

### Data sharing with third parties

We share your personal data with our contractors in the scope we need to provide services.

#### Details

We share your data on the following grounds:

1. **Performance of a contract.** We may transfer your data to our contractors and partners for contractual purposes.
2. **Consent.** We may transfer your personal data based on your explicit consent.
3. **Compliance with the law.** We may disclose your personal data to third parties to the extent that it is necessary:
   * to comply with a government request, court order, or applicable law;
   * to prevent unlawful use of our App or policies;
   * to protect against claims of third parties;
   * to help prevent or investigate fraud.
4. **Transfer to third parties.** We may transfer your personal data to third parties based on a data processing agreement, subject to applying technical and organisational measures to protect your personal data. We may share data with certain companies, consultants and contractors hired to provide certain services on our behalf.

<Info>
  Please note! We will ask for your consent if data transfer is not part of the contract.
</Info>

### Data protection

We use different organisational, physical, and security measures presented below. We are constantly improving these measures, so there may be more of them as you read them.

| Storing documents in separate data storage | Encryption | Provision of access to personal data only to authorised persons |
| - | - | - |
| Password Policy | Licensed antivirus software | Internet, email policies |
| Two-factor authentication | Backuping | Other security measures |

### Data subjects rights

You, as a data subject, have the right to interact with your data directly or through a request to us. This section describes these rights and how you can exercise them:

| The right | Description |
| - | - |
| Right to access. | You can request an explanation of the processing of your personal data. |
| Right to rectification. | You can change the data if it is inaccurate or incomplete. |
| Right to erasure. | You can send us a request to delete your personal data from our systems. We will remove them unless otherwise provided by law. |
| Right to restrict the processing. | You may partially or completely prohibit us from processing your personal data. |
| Right to data portability. | You can request all the data that you provided to us, as well as request to transfer data to another controller. |
| Right to object. | You may object to the processing of your personal data. |
| Right to withdraw consent. | You can withdraw your consent at any time. |
| Right to file a complaint. | If your request was not satisfied, you can file a complaint to the regulatory body. |

<Note>
  To exercise your rights, [contact us](mailto:extractor@hacken.io).
</Note>

If your request was not satisfied, you can file a complaint with the regulatory body — the Data Protection Inspectorate, at [info@aki.ee](mailto:info@aki.ee) or write a letter to 39 Tatari St., 10134 Tallinn.

### Cookies

We use cookies that are needed for the App's operation. By using cookies, we receive automatically collected data. You can read more in our [Cookies Policy](/legal-documents/cookie-policy).

If you want to disable cookies, you can find instructions for managing your browser settings at these links:

| | | | |
| :-: | :-: | :-: | :-: |
| [Internet Explorer](https://support.microsoft.com/en-us/help/17442/windows-internet-explorer-delete-manage-cookies) | [Firefox](https://support.mozilla.org/en-US/kb/cookies-information-websites-store-on-your-computer) | [Chrome](https://support.google.com/chrome/answer/95647) | [Opera](https://help.opera.com/en/latest/web-preferences/) |
| [Microsoft Edge](https://privacy.microsoft.com/en-us/windows-10-microsoft-edge-and-privacy) | [Vivaldi](https://help.vivaldi.com/article/privacy-settings/) | [Safari](https://support.apple.com/guide/safari/manage-cookies-and-website-data-sfri11471/) | [Brave](https://support.brave.com/hc/en-us/articles/360050634931-How-Do-I-Manage-Cookies-In-Brave-) |

### Update

This Privacy Notice and the relationships falling under its effect are regulated by the Regulation (EU) 2016/679 ("GDPR").

Existing laws and requirements for the processing of personal data are subject to change. In this case, we will publish a new version of the Privacy Notice on our App.

If significant material changes are made that affect your privacy and confidentiality, we will notify you by displaying information on the App and ask for your consent.


# Terms of Service
Source: https://docs.extractor.live/legal-documents/terms-of-service

Hacken Extractor terms of service — usage rights, account responsibilities, billing, warranties, and limitations of liability. Updated 18 July 2024.

By these Terms of Service ("Terms") Hacken OÜ ("Company", or "we") provides you ("you", or "user") with the essential information about your legal rights and obligations related to your use of our web application "Extractor", available via the link – [https://extractor.hacken.io/](https://extractor.hacken.io/) ("Extractor", or "App").

Please, read the Terms carefully before accessing the App. If you disagree with these Terms, please do not continue using the App.

By using the App, you declare and warrant that:

* you have read, understand, and hereby agree to be legally bound by and to comply with these Terms in full;
* you have full legal capacity, which means you have reached the legal age and are not restricted otherwise (otherwise, you can use the App exclusively with the involvement of a parent or guardian);
* if you act on behalf of the legal entity, you are duly authorized to represent such an entity to enter into this Agreement;
* according to your local jurisdiction, you are eligible to enter into this agreement and have no restriction to access or use the App. Otherwise, Extractor is not intended for you, and we ask you not to use it. You are responsible for informing yourself of the laws of your jurisdiction and complying with them.
* you comply with these Terms and all applicable laws and regulations.

Our [Privacy Notice](/legal-documents/privacy-notice) describes our collection and use of personal data connected to your access to and use of the App.

These Terms and any operating rules and policies posted on the App, including Privacy Notice, constitute the entire legally binding agreement ("Agreement") and understanding between us and our users, governing your access to and use of the App.

*If you have any questions or comments about these Terms, please* [*contact us*](mailto:extractor@hacken.io)*.*

### Content

[**The App**](#the-app)

[**Account**](#account)

* [Account registration and use](#account-registration-and-use)
* [Problems with the Account](#problems-with-the-account)
* [Delete the Account](#delete-the-account)

[**Payment**](#payment)

[**The App's features and functionality**](#the-apps-features-and-functionality)

[**Content and intellectual property**](#content-and-intellectual-property)

[**Third-party websites and services**](#third-party-websites-and-services)

[**Warranties and disclaimers**](#warranties-and-disclaimers)

[**Liability**](#liability)

[**Indemnification**](#indemnification)

[**Applicable law and jurisdiction**](#applicable-law-and-jurisdiction)

[**Termination**](#termination)

* [Termination by the Company](#termination-by-the-company)
* [Termination by the user](#termination-by-the-user)

[**Electronic notifications**](#electronic-notifications)

[**Other terms**](#other-terms)

[**Questions and contact information**](#questions-and-contact-information)

### The App

Hacken Extractor is an advanced on-chain smart contract security system that provides real-time monitoring of your smart contracts and alerts you of any suspicious activity to prevent potential hacks.

### Account

#### Account registration and use

To use all App's features, you must complete authorization and create a personalized account ("Account"). Enter your email address and create a password in the special page of the App to do so. We will email you at the previously specified address to verify it.

In addition, you may use your Google account for authorization in the App.

For every following login into the App, use your email and a created password or Google account.

#### Problems with the Account

You may not transfer or assign your Account to someone else.

Please, immediately [contact us](mailto:extractor@hacken.io) if:

* you know or have any reason to suspect that someone has gained access to your Account without your authorization;
* your credentials have been lost, stolen, misappropriated, or otherwise compromised.

#### Delete the Account

To delete the Account in the App, please, [contact us](mailto:extractor@hacken.io).

### The App's features and functionality

Hacken Extractor continuously monitors your smart contracts and checks every transaction against the specific condition or set of conditions set by you ("Triggers").

If these conditions are met, the monitoring system will alert you in real-time, providing complete monitoring of your smart contracts.

Some of the Triggers are enabled for every smart contract by default, some of them you may set by your own parameters. You may find the description of all Triggers in the App.

The number of smart contracts you are eligible to add depends on the chosen subscription plan, if applicable. Choose the appropriate subscription plan, and get more payment details by [contacting us](mailto:extractor@hacken.io).

To put the smart contracts under the App's monitoring, you shall:

* Select how you would proceed with a Trigger setup: automatically or manually. We recommend choosing automatically because you'll get personal monitoring recommendations based on your smart contract type. But you may customize them to meet your specific security needs, ensuring that the monitoring system only reacts to important events.
* Add a smart contract to your monitoring list. You must specify its address, type and ABI;
* Choose the way you will get the monitoring notifications.

In addition, you may personally name every smart contract.

Once setup is complete, smart contract monitoring is active, and you'll receive notifications if any of the Triggers are met.

You may delete any smart contract from the monitoring list at any time.

#### Smart Contract Actions

You may perform the smart contract function if the Trigger notifies you about the threats to it (for instance, put the smart contract on hold). This functionality is paid.

To obtain such functionality, you shall:

* create your own contract action provider through the App and give Extractor the right to perform the actions with your smart contract;
* replenish the balance of the contract action provider. Extractor calculates the approximate fee for set transactions by you ("Action Fee");
* set the parameters of actions that may be performed with the contract action provider ("Contract Action") (you may set Contract Action for every Trigger).

If all the contract action parameters for the Trigger are set, and the necessary amount of Action Fee is on the contract action provider balance – when the Trigger activates, the chosen smart contract function will be performed. In addition, you may perform the smart contract function yourself.

The exact amount of the Action Fee will be deducted from your balance after performing the corresponding function in response to the Trigger.

The chosen smart contract function may be activated if the contract action provider balance is replenished on the amount not less than the Action Fee to perform it.

You may withdraw the unused sums you deposited on the contract action provider balance.

### Payment

The user is obliged to pay the full amount of the subscription plan within the term indicated on the invoice.

The appropriate subscription plan should be activated within 90 days from the date the invoice is paid. (**"Activation period"**)

If the subscription plan is not activated by the user within this Activation period, the Company will automatically activate it the next day after the activation period is over.

### Content and intellectual property

All materials in the App, including text, graphics, information, images, drawings, trademarks, logos, software, and other materials ("Content"), as well as copyright and other intellectual property rights to such Content belong to us or are included in the App with the consent of the owner.

The Content, or any elements thereof, may not be used without our or the owner's prior written consent in any manner not provided by these Terms.

If you comply with these Terms, we grant you a limited, worldwide, non-exclusive, revocable license, without the right to sublicense and transfer, for the period of your use of the App, to access and use the App for your personal, non-commercial use, and business purposes under these Terms.

You must not:

* reproduce, publish, distribute, modify, create, or otherwise use the Content we own for commercial or illegal purposes without our prior written consent;
* sell, lease, rent, license, sublicense, or otherwise distribute the Content we own;
* copy, decompile, disassemble, translate, or reverse engineer the Content we own, in whole or in part;
* write or develop any derivative software, make an attempt to derive the source code of, modify, or create derivative works of the Content we own, and its updates;
* provide, disclose, divulge or make available to, or permit the use of the Content we own by any third party without our prior written consent;
* avoid, bypass, remove, deactivate, impair, descramble, or otherwise circumvent any technological measure we implement or any of our providers or any other third party (including another user) to protect the Content we own.

### Third-party websites and services

The App may contain links to other websites and services governed by third parties.

We do not control the features available or accessed through such websites and services.

We are not responsible for the content and services offered through them, and for any losses, damages, or other liabilities incurred as a result of your use of such websites and services.

You acknowledge that other terms of use and privacy notices apply to your use of third-party websites, services, and content.

### Warranties and disclaimers

The App is provided to you "as is".

To the fullest extent permitted by law, we disclaim all warranties concerning the App, its functionality, and its Content, including, without restrictions, warranties of fitness for a particular purpose, merchantability, and non-infringement of intellectual property rights of third parties or other rights.

We make no promises or guarantees regarding the accuracy, usefulness, reliability, and correctness of the App. We do not warrant that the operation of the App will be uninterrupted or secure, that any defects will be corrected, or that the App will be free of viruses or other harmful elements.

We use best industry practices but do not warrant that all Triggers will work smoothly and efficiently (set up automatically and manually); all the threats, attacks, and other unauthorized effects on your smart contracts will be detected by the App and notified timely.

We do our best to keep data safe and secure and maintain the App's functionality. However, the App may be unavailable for various factors beyond our control, including emergencies, third-party service failures, hacker attacks, transmission, equipment or network problems or limitations, interference, and signal strength, and may be interrupted, refused, limited, or curtailed.

The App's functionality is based on industry standards and general practices, and in no way guarantee or promise any outcomes even mentioned hereto.

The Company is not responsible if the information provided in the App, and the contact information you have acquired is inaccurate, incomplete, or unreliable. Any inaccuracies / errors may arise from time to time in the Content, the work of Triggers and we try to correct them as soon as possible. Please [let us know](mailto:extractor@hacken.io) if you noticed any incorrect information in the App.

We are not responsible for the use by other users and third parties of any personal data you make publicly available in the App.

### Liability

We shall not be held responsible if any information, materials, or the Content available through the App is inaccurate or incomplete and for typographical errors, omissions in the text, or other materials.

In no event shall we or our subcontractors or any other team members be liable for:

* any direct, indirect, incidental, special, consequential, or incidental damages, including lost profits, loss of data, or damage to property, related to the use or inability to use the App; and
* any damage caused by the use of information obtained through the App; and
* any damage caused by any errors, defects, and interruptions in the App.

The above disclaimer applies to the extent permitted by applicable law.

### Indemnification

You agree to defend, indemnify and hold harmless us from and against all claims, responsibility, damages, losses, and expenses, including reasonable legal and accounting expenses, arising from:

* any breach by you of any of these Terms;
* your use/misuse of the App;
* a violation by you of applicable law, our or third party's intellectual property or other rights, or any agreement or terms with a third party to which you are subject.

We reserve the right to handle our legal defense; however, we see fit, including instances when you indemnify us. Therefore, you agree to cooperate with us to execute our strategy.

### Applicable law and jurisdiction

These Terms shall be exclusively governed by and construed under the laws of the Republic of Estonia, excluding its rules on conflict of laws.

You agree that any dispute, conflict, claim, or controversy directly or indirectly arising out of in connection with or relating to these Terms, including, without limitation, those relating to its validity, its construction, or its enforceability shall be settled through amicable negotiations directly with the Company following the principles of good faith and cooperation.

If attempts to reach a consensus through the negotiations fail, the dispute shall be settled exclusively by the Arbitration Court of the Estonian Chamber of Commerce and Industry (Tallinn, Estonia).

The arbitration shall be settled by one arbitrator whose decision is final. The language of the arbitration shall be English if the Parties do not agree otherwise.

### Termination

#### Termination by the Company

We reserve the right at our sole discretion with or without prior notice to modify, suspend or discontinue the App, Content, feature, or offers through the App at any time. You agree that we shall not be liable to you or any third party should any of the preceding occur.

We reserve the right to take whatever lawful actions we may deem appropriate in response to actual or suspected violations of these Terms, including, without limitation, the suspension or termination of your license and access to the App.

We may cooperate with legal authorities and third parties to investigate any suspected or alleged crime or civil wrong.

#### Termination by the user

You may terminate these Terms by deleting all the smart contracts from the App, deleting your Account and no longer accessing or using the App.

If you terminate these Terms, all permissions and licenses under these Terms will immediately terminate, and you will no longer obtain Trigger notifications through the App.

### Electronic notifications

By using the App and providing us with your contact details, you understand and agree that we may send you electronic notifications via email, Telegram, Slack, and Discord ("Notification tools") regarding, without limitation:

* your use of the App (including the notifications about the Triggers chosen for your smart contracts previously);
* updates of the App and these Terms;
* news, community activities, information about referral programs, promotions, retention emails, and other marketing content.

You may unsubscribe from all notifications about the Triggers by disabling the corresponding option in the Triggers list, or by disabling each Notification tool in each Triggers settings.

You may unsubscribe from email notifications at any time, by clicking the corresponding button, provided in every notification.

### Other terms

We may transfer our rights and obligations under these Terms to a third party, but this will not affect your rights or our obligations.

At our sole discretion, we reserve the right to modify these Terms. If material changes affect your use of the App, we will notify you before the changes' effective date by sending a notification to you. If you continue to use the App, you agree to the updated version of these Terms.

If you disagree with the updated version of these Terms, please delete and no longer use or access the App.

If any provision of these Terms is determined to be unlawful, void, or unenforceable, the remaining provisions of these Terms will continue to be fully valid and enforceable.

A printed version of these Terms shall be admissible in judicial or administrative proceedings based on or relating to the use of the App to the same extent and subject to the same conditions as other business documents and records originally generated and maintained in printed form.

### Questions and contact information

If you have any questions or comments about these Terms or the App, please contact us at [extractor@hacken.io](mailto:extractor@hacken.io).

| | |
| - | - |
| **Data Controller** | Hacken OÜ |
| **Registry code** | 14351915 |
| **Address** | Harju maakond, Tallinn, Kesklinna linnaosa, Parda tn 4, 10151, Estonia |


# Monitoring and Detection
Source: https://docs.extractor.live/monitoring-and-detection

Overview of the four monitoring types in Hacken Extractor — security, financial, compliance, and advanced monitoring — and how to choose between them.

Hacken Extractor organizes monitoring into four specialized layers. Each targets a different risk surface — from on-chain attack detection to regulatory compliance and financial health.

<CardGroup>
  <Card title="Security Monitoring" icon="shield" href="/security-monitoring/intro">
    Real-time detection of on-chain threats — AML flags, address poisoning, block anomalies, and asset flow tracking. Built for security teams responding to active incidents.
  </Card>

  <Card title="Advanced Monitoring" icon="sliders" href="/advanced-monitoring/intro">
    Custom triggers that fire on specific contract events — ERC-20 transfers above a threshold, function calls, blacklisted callers, and more. Built for teams with precise monitoring needs.
  </Card>

  <Card title="Compliance Monitoring" icon="scale-balanced">
    Tracks price feeds, token supply, TVL, DNS records, and GitHub activity. Surfaces deviations that may indicate regulatory exposure or protocol integrity issues.
  </Card>

  <Card title="Financial Monitoring" icon="chart-line">
    Monitors balances, circulation supply, multisig state, and token flows. Designed for treasury teams and protocols that need continuous financial health visibility.
  </Card>
</CardGroup>

## How they work together

<Steps>
  <Step title="Security Monitoring catches threats first">
    Detectors run continuously against every block and transaction, flagging known bad actors, anomalous blocks, and suspicious fund flows in real time.
  </Step>

  <Step title="Advanced Monitoring covers custom logic">
    Where built-in detectors don't fit, triggers let you define your own conditions — any function call, event, transfer pattern, or caller restriction.
  </Step>

  <Step title="Compliance and Financial Monitoring track health over time">
    Scheduled checks evaluate price deviations, supply changes, balance thresholds, and external data sources on a configurable cadence.
  </Step>

  <Step title="Alerts route to your team">
    All monitoring types emit structured alerts with severity levels and full transaction context, delivered to your configured notification channels.
  </Step>
</Steps>


# Multi-Channel Notifications
Source: https://docs.extractor.live/notifications

Deliver Hacken Extractor alerts to Email, HTTP webhooks, Telegram, and Slack so your team is notified the moment a detector or trigger fires.

Hacken Extractor routes every alert to the notification channels you configure. Connect as many channels as you need and send each alert to the right people, in the tools they already use.

<CardGroup>
  <Card title="Email" icon="envelope">
    Send alerts to any email address. Adding a notification email does not change your account's primary email.
  </Card>

  <Card title="HTTP" icon="globe">
    Post alerts to your own HTTP endpoint (webhook) to feed SIEMs, incident tooling, or custom automation.
  </Card>

  <Card title="Telegram" icon="telegram">
    Deliver alerts to a Telegram chat or group for instant mobile notifications.
  </Card>

  <Card title="Slack" icon="slack">
    Post alerts to a Slack channel so your team can triage them together.
  </Card>
</CardGroup>

## Create a notification channel

<Steps>
  <Step title="Open notification settings">
    Go to **Settings** and open the **Notifications** tab.
  </Step>

  <Step title="Add a channel">
    Click **Create notification channel** and choose the channel type: **Email**, **HTTP**, **Telegram**, or **Slack**.
  </Step>

  <Step title="Enter the destination">
    Fill in the details for the selected type, for example the email address or the HTTP endpoint URL, then click **Create**.
  </Step>

  <Step title="Attach it to your monitoring">
    When configuring a detector or trigger, select one or more channels under **Notification Channels**. Every alert it emits is delivered to all selected channels.
  </Step>
</Steps>

<Tip>
  Combine channels by severity: for example, route `CRITICAL` and `HIGH` alerts to Telegram or Slack for immediate response, and send lower-severity alerts to email for review. See [Severity](/common-configurations#severity).
</Tip>


# Address Poison
Source: https://docs.extractor.live/security-monitoring/detectors/address-poison

Detector monitor for transaction history poisoning with fake addresses

Detector monitor for transaction history poisoning with fake addresses

## Functionality

* Detector monitors transaction history for injection of fake transactions and events which resemble monitored address.

Poisoned address looks very similar in history because first and last 2-3 bytes are identical.

Copy-pasting poison address from history can result in funds loss

* Mask for matching address to poisoning pattern.
* How many historical transaction to check for poisoning
* How far into the past to keep transactions history (in milliseconds)

## Configuration

* **Past** (`past`, default: `2592000000`): How long to monitor history into the past
* **History** (`history`, default: `25`): How many past transactions to monitor
* **Patterns** (`patterns`, default: `['0xffff00000000000000000000000000000000ffff']`): Address match patterns
* **Severity** (`severity`, default: `0.5`): Severity See [common configuration](/common-configurations#severity).

<Note>
  Supported networks: ethereum, bsc.
</Note>


# Block Anomaly
Source: https://docs.extractor.live/security-monitoring/detectors/block-anomaly

Monitors blocks for Block anomalies. Anomalies includes transaction count (low/large), large block size, large number of Events, etc

Monitors blocks for Block anomalies.
Anomalies includes transaction count (low/large), large block size, large number of Events, etc

## Functionality

* Conditions for min and max transaction count in a block
* Conditions for min and max gas used in a transaction. Use `GasMonitor` for more gas related monitors
* Conditions for min and max events count in a block
* Conditions for block size (min/max)
* Large and small Gas usage in block
* Expected Block frequency (max/min) (msec). This informaiton is extracted from block timestamps.
* Liveness check for block generation. Alert is triggered if **no** blocks are generated within the conditiion (E.g. `> 25000` means block is expected within 25 sec )
* Track block latency. It is updated evey 10 min

## Configuration

* **Transactions min** (`tx_min`, default: `<1`): Minimal transaction in block
* **Transactions max** (`tx_max`, default: `>2000`): Maximal transaction in block
* **Events min** (`event_min`, default: `<1`): Minimal Events in block
* **Events max** (`event_max`, default: `>3000`): Maximal Events in block
* **Block size min** (`block_min`, default: `<100`): Minimal block size
* **Block size max** (`block_max`, default: `>10000000`): Maximal block size
* **Gas min** (`gas_min`, default: `<22000`): Minimal gas used in a block
* **Gas max** (`gas_max`, default: `>29999000`): Max gas used in a block
* **Gas min (Tx)** (`tx_gas_min`, default: `<20000`): Minimal gas used in a Transaction
* **Gas max (Tx)** (`tx_gas_max`, default: `>10000000`): Max gas used in a Transaction
* **Cron** (`cron`, default: `60 sec`): Periodic check for anomalies See [common configuration](/common-configurations#cron).
* **Track Latency** (`lat_enabled`, default: `False`): Track Blocks Latency
* **Block Freq (min)** (`block_freq_min`, default: `<1000`): Min Block creation interval
* **Block Freq (max)** (`block_freq_max`, default: `>12500`): Max Block creation interval
* **Liveness interval** (`liveness`, default: `> 25000`): Liveness interval threshold
* **Severity** (`severity`, default: `-1.0`): Severity See [common configuration](/common-configurations#severity).

<Note>
  Supported networks: evm.
</Note>


# Block Reorg
Source: https://docs.extractor.live/security-monitoring/detectors/block-re-org

Detector monitors Blockchain for Block reorgs

Detector monitors Blockchain for Block reorgs

## Functionality

* Protocol Layer reorg is when blockchain replaces blocks with another sub-chain.

Previously observed block at re-org depth will not be part of blockchain

* How deep reorg to monitor for

## Configuration

* **Depth** (`depth`, default: `2`): Depth or reorg to detect
* **Severity** (`severity`, default: `-1`): Severity See [common configuration](/common-configurations#severity).

<Note>
  Supported networks: ethereum.
</Note>


# Chainabuse Monitor
Source: https://docs.extractor.live/security-monitoring/detectors/chainabuse-monitor

Detector monitors Chainabuse alerts

Detector monitors Chainabuse alerts

## Functionality

* Chainabuse categories list to filter (`PHISHING`,`OTHER_HACK`, ...). Use `!` prefix to exclude category.

If empty, all categories will be alerted

See Chainabuse documentation for supported categories

* Cron expression for interval to check. Reports are cached internally.

Cron expression can be Quartz syntax, milliseconds value or seconds/minutes/hours/days expression (e.g. `5 hours`)

Example: `0 0 12 1/1 * ? *`

## Configuration

* **Category** (`category`, default: \`\`): Categories to filter
* **Cron** (`cron`, default: `1 day`): Check Interval See [common configuration](/common-configurations#cron).
* **Severity** (`severity`, default: `0.2`): Severity See [common configuration](/common-configurations#severity).

<Note>
  No specific network configuration required (Any network).
</Note>


# Chainlink ACE Monitor
Source: https://docs.extractor.live/security-monitoring/detectors/chainlink-ace-monitor

Monitors Contract under Chainlink [Automated Compliance Contract](https://chain.link/automated-compliance-engine) Engine. It understands all ACE Entities and can detect configuration changes, policy violations, transfers and contract calls. CCIP Tracking supports tracking any tokens (no monitored address)

Monitors Contract under Chainlink [Automated Compliance Contract](https://chain.link/automated-compliance-engine) Engine.

It understands all ACE Entities and can detect configuration changes, policy violations, transfers and contract calls.

CCIP Tracking supports tracking any tokens (no monitored address)

## Functionality

* Detects all ACE Events
* Detects all Policy Rejections (Transactions `reverts`)
* Detects Contract token transfers (if token is ERC-20 compatible)
* Detects function calls
* Detects CCIP Transfers
* Track Condition for transfers (e.g. `> 0`)

NOTE: In token denomination (not decimals)

* Track Contract function calls
* Track CCIP Transfers
* Track Failed transactions. Policy Rejections are failed transactions!
* Track ACE Events

## Configuration

* **Description** (`desc`, default: `{reason}{func}{input}{amount} {sym}{err}`): Description pattern
* **Track Failed** (`track_failed`, default: `True`): Track Failed and Rejections
* **Track calls** (`track_calls`, default: `True`): Track Contract calls
* **Track CCIP** (`track_ccip`, default: `True`): Track CCIP Transfers
* **Track Events** (`track_events`, default: `True`): Track ACE Events
* **Track Transfers** (`track_transfers`, default: `> 0`): Track ERC20 Transfers Condition
* **Severity** (`severity`, default: `-1`): Severity See [common configuration](/common-configurations#severity).

<Note>
  Supported networks: ethereum\_sepolia, base\_sepolia.
</Note>


# Contract Call
Source: https://docs.extractor.live/security-monitoring/detectors/contract-call

Execute calls to contract function (not transaction), extracts results and check conditions

Execute calls to contract function (not transaction), extracts results and check conditions

## Functionality

* Function to execute.
  It must be a full signature in the [foundry cast](https://getfoundry.sh/cast/reference/cast) format

(e.g. `balanceOf(address)(uint256)`)

* Parameters to pass to the function.
  Parameters can be separated with spaces or new lines.

Tuples must be enclosed in `()`.

Arrays must be enclosed in `[]`

Strings must be enclosed in `""`

Refer to [cast](https://getfoundry.sh/cast/reference/cast) documentation for syntax

* Sender address (optional). If not specified, the contract address will be used as sender.
* Cron interval to execute call (for `cron` **When** mode). Refer to [Cron](https://docs.extractor.live/common-configurations#cron) for more details
* Scripts to execute

Scripts are executed in the order they are specified. Refer to [Scripts](https://docs.extractor.live/common-configurations#condition-threshold) for more details.

Scripts execution result will be in `result` meta field.

* When to execute script:

`block` - every block
`cron` - at cron intervals

* Desciption field pattern. Metadata fields from Alert can be used as Substitutions and must be enclosed in `{}`

Example: `{func}: {result}`

* Generate Alerts on Errors (in Contract Call or Evaluation Script)
* Alert on every Error. If `unchecked`, only new unique Errors will be alerted and duplicates will be omitted

## Configuration

* **When** (`when`, default: `cron`): When to call the contract
* **Cron** (`cron`, default: `10 min`): Interval to execute See [common configuration](/common-configurations#cron).
* **Function** (`func`, default: `None`): Function signature (foundry format)
* **Parameters** (`params`, default: \`\`): Function parameters
* **Sender** (`sender`, default: \`\`): Sender address (optional)
* **Scripts** (`script`, default: `[]`): Scripts to execute
* **Track Errors** (`track_err`, default: `True`): Track Call/Script error
* **Track Errors (always)** (`err_always`, default: `False`): Always Alert on Error
* **Description** (`desc`, default: `{func}: {result}{err}`): Description Pattern
* **Severity** (`severity`, default: `-1`): Severity See [common configuration](/common-configurations#severity).

<Note>
  Supported networks: ethereum, ethereum\_sepolia, hyperevm, base.
</Note>


# Contract Hash Verification
Source: https://docs.extractor.live/security-monitoring/detectors/contract-hash-verification

Contract Hash Verification for detecting changes in a contract bytecode

Contract Hash Verification for detecting changes in a contract bytecode

## Functionality

* The contract hash verification detector continuously monitors the Ethereum Virtual Machine (EVM) network for real-time contract upgrade events. It consumes transaction data, specifically looking for an UPGRADED event emitted by smart contracts. Upon detecting an upgrade event, the detector fetches the bytecode of the updated contract, calculates its hash, and compares it with a provided expected hash hash. Any discrepancies trigger a notification, which is sent to Extractor.
* The type of hash function used to calculate the checksum of the compiled bytecode of the smart contract to be verified. Supported hash functions are Keccak and SHA256. Default value is Keccak.
* The Kaccak checksum of the compiled bytecode of the smart contract to be verified
* Perform an initial check to verify the contract bytecode
* No notification is sent in this case, as the process completed successfully without any discrepancies in the contract bytecode
* The contract bytecode mismatched the expected checksum, triggering a notification with details about the discrepancy

## Configuration

* **Hash Type** (`hash_type`, default: `keccak`): Hash Type
* **Contract Bytecode Checksum** (`checksum`, default: `None`): Contract Bytecode Checksum
* **Initial Check** (`initial_check`, default: `True`): Perform initial bytecode check
* **Severity** (`severity`, default: `-1.0`): Severity See [common configuration](/common-configurations#severity).

<Note>
  Supported networks: evm.
</Note>


# Contract Verification
Source: https://docs.extractor.live/security-monitoring/detectors/contract-verification

Contract Verification sentry for detecting changes in a contract

Contract Verification sentry for detecting changes in a contract

## Functionality

* The monitor tracks an EVM network for the `Upgraded` event emitted by smart contracts. Upon detecting an `Upgraded` event, the monitor triggers a contract build process to  verify the checksum of the implementation bytecode on the blockchain against a locally compiled version of the bytecode.
* The name of the smart contract to be tracked and verified
* The URL of the Git repository where the smart contract source code is stored.
* The specific commit hash in the Git repository that corresponds to the contract's source code version to be compiled
* The path within the Git repository where the smart contract source code is located. This should be a relative path from the root of the repository.
* No notification is sent in this case, as the process completed successfully without any issues and the locally compiled bytecode matches the bytecode deployed on the blockchain
* The contract build process fails due to issues such as: incorrect repository URL or commit hash, compilation errors due to missing dependencies, syntax errors, or incompatible Solidity versions, incorrect build path or missing source files, etc. As result, the monitor sends a notification with details about the failure
* The build process completes successfully, but the checksum of the compiled bytecode does not match the bytecode on the blockchain. The monitor sends a notification with details about the checksum mismatch

## Configuration

* **Contract Name** (`contract_name`, default: `None`): Contract Name
* **Respository URL** (`repo_url`, default: `None`): Git Repository URL
* **Commit Hash** (`commit_hash`, default: `None`): Git Respository Commit Hash
* **Build Path** (`build_path`, default: `/`): The build path in Git Repository
* **EVM Version** (`evm_version`, default: `None`): Compiler EVM Version
* **Severity** (`severity`, default: `-1.0`): Severity See [common configuration](/common-configurations#severity).

<Note>
  Supported networks: evm.
</Note>


# DNS Monitor
Source: https://docs.extractor.live/security-monitoring/detectors/dns-monitor

Detector monitors DNS for potential attacks (like DNS Hijacking)

Detector monitors DNS for potential attacks (like DNS Hijacking)

## Functionality

* Detector monitors WHOIS and DNS server records for changes
* WHOIS is mulitple registries for domains registration infomation
* Nameservers for Domain resolution.

If Nameserver field is empty, it will not be checked.

* List of IP addresses domain is resolved to. Use `,` (semicolon) for mulitple IP addresses
* It is a date when to start alerting about Domain expiration. It should be before Domain expiration date.

Use date format, not time should be specified (e.g. `2026-01-25`)

If no value is specified expiration will not be checked.

* Cron expression (Quartz expression syntax, millisecond value or seconds/minutes/hours expression)

Periodic check example: `10 min`

Cron expression is Quartz syntax example for every hour:  `0 0 0/1 1/1 * ? *`"

## Configuration

* **Cron** (`cron`, default: `10 min`): Cron expression to check DNS See [common configuration](/common-configurations#cron).
* **Domain** (`domain`, default: \`\`): Domain to monitor
* **IP address(s)** (`ip`, default: \`\`): List of expected resolved addresses
* **NS1** (`ns1`, default: \`\`): Nameserver
* **NS2** (`ns2`, default: \`\`): Nameserver
* **NS3** (`ns3`, default: \`\`): Nameserver
* **NS4** (`ns4`, default: \`\`): Nameserver
* **Expiry Alert date** (`expiry_alert`, default: \`\`): The date when to start alerting about expriration
* **Severity** (`severity`, default: `-1`): Severity See [common configuration](/common-configurations#severity).

<Note>
  No specific network configuration required (Any network).
</Note>


# Due Diligence
Source: https://docs.extractor.live/security-monitoring/detectors/due-diligence

Automatically runs due diligence reports for DeFi protocols. Given a protocol name and a set of URLs or seed addresses, the detector triggers an automated DD workflow that discovers contracts, verifies audits, researches security posture, and generates a scored Markdown + JSON report. Emits progress alerts at each pipeline stage, human-in-the-loop review gates, and on completion with download links for the Markdown, JSON, and PDF reports.

Automatically runs due diligence reports for DeFi protocols. Given a protocol name and a set of URLs or seed addresses, the detector triggers an automated DD workflow that discovers contracts, verifies audits, researches security posture, and generates a scored Markdown + JSON report. Emits progress alerts at each pipeline stage, human-in-the-loop review gates, and on completion with download links for the Markdown, JSON, and PDF reports.

## Functionality

* See configuration parameters below.

## Configuration

* **Protocol Name** (`protocol_name`, default: `None`): Display name of the protocol (e.g. 'EtherFi'). Used in the report header.
* **Protocol Slug** (`protocol_slug`, default: `None`): URL-safe identifier (e.g. 'etherfi'). Used as the S3 prefix and Temporal workflow ID. Must be unique per protocol — changing it starts a brand new run. Derive from protocol\_name: lowercase, spaces to hyphens (e.g. 'My Protocol' → 'my-protocol').
* **GitHub Organisation** (`github_org`, default: `None`): GitHub organisation handle (e.g. 'etherfi-protocol'). Enables repo scanning, fork detection, and audit PDF discovery from GitHub.
* **Docs / Contract List URLs** (`docs_urls`, default: `[]`): Pages listing deployed contract addresses (GitBook, Notion, protocol docs). At least one of docs\_urls, security\_urls, github\_org, or seed\_addresses is required.
* **Security / Audit URLs** (`security_urls`, default: `[]`): Audit pages, GitHub /audits folders, or direct PDF links. The more context provided, the richer the output.
* **Customer Name** (`customer_name`, default: `None`): Legal client name for the report header. Defaults to Protocol Name if not set.
* **Auto-Approve (Skip HITL Gates)** (`auto_approve`, default: `False`): When False (default), the workflow pauses at two human-in-the-loop review gates. When True, the workflow runs fully autonomously without any human review.
* **Clean Run** (`is_clean_run`, default: `False`): When True, all previous database and S3 data for this protocol\_slug is deleted before starting a new run. Use to force a full re-analysis.
* **Mock Run** (`is_mock_run`, default: `False`): When True, the workflow performs a simulated run without executing real transactions or external state changes. Use for testing configurations.
* **Researcher Notes** (`researcher_notes`, default: `None`): Free-text analyst prior passed to the DD workflow as additional context (e.g. known risks, recent incidents, scope hints). Max 2000 characters.
* **Website URL** (`website_url`, default: `None`): Protocol website (e.g. '[https://ether.fi](https://ether.fi)'). Auto-derived from docs\_urls if omitted.
* **Registry URLs** (`registry_urls`, default: `[]`): GitHub repos containing .sol or JSON address files (e.g. euler-interfaces).
* **Seed Addresses** (`seed_addresses`, default: `[]`): Known contracts to seed contract discovery. Format: chain\_id (int), address (0x...), optional label.
* **Protocol Category** (`protocol_category`, default: `general`): Category used for scoring context. One of: general, Lending, DEX, Yield, Bridge, Staking, Derivatives, CDP, RWA.
* **Report Tags** (`report_tags`, default: `due-diligence,dd,ai`): Comma-separated tags attached to the generated PDF report in the Reports API.
* **Track Errors** (`track_errors`, default: `True`): When True, the detector sends alerts with internal errors.

<Note>
  No specific network configuration required (Any network).
</Note>


# Attack Detector
Source: https://docs.extractor.live/security-monitoring/detectors/extractor-attack-detector

Attack Detector identifies any unusual activity and gathers information on suspicious accounts and contracts to prevent potential harmful interactions from suspicious addresses.

Attack Detector identifies any unusual activity and gathers information on suspicious accounts and contracts to prevent potential harmful
interactions from suspicious addresses.

## Functionality

* This alert triggers when a transaction from a suspicious account is directed towards an address you are monitoring. This helps you keep track of potentially harmful interactions that could affect your assets.
* If a transaction to your monitored address includes internal calls from a suspicious contract, an alert is issued to inform you of these potentially hidden interactions.
* When a new contract is created under dubious circumstances and involves addresses you monitor, you'll receive an alert. This ensures you're aware of new threats that may target your contracts directly

## Configuration

* No configurable parameters beyond the standard detector settings.

<Note>
  Supported networks: evm.
</Note>


# Forta Detector
Source: https://docs.extractor.live/security-monitoring/detectors/forta-detector

ML and Heuristics based monitoring by Forta. Triggers when a malicious event is observed in the preparation stage of the attack process.

ML and Heuristics based monitoring by Forta.  Triggers when a malicious event is observed in the preparation stage of the attack process.

## Functionality

* Forta Network: [https://app.forta.network](https://app.forta.network)

## Configuration

* No configurable parameters beyond the standard detector settings.

<Note>
  Supported networks: evm.
</Note>


# Gas Monitor
Source: https://docs.extractor.live/security-monitoring/detectors/gas-monitor

Detector monitors gas related parameters

Detector monitors gas related parameters

## Functionality

* Average Price threshold in gwei. (Ex: **>150.0**)
* Max Price threshold in gwei. (Ex: **>250.0**)
* Min Price threshold in gwei. (Ex: **\<1.0**)
* Max Cost (price \* gas) threshold in Eth (`gwei * 1^dec`). (Ex: **> 0.1**)
* Min Cost (price \* gas) threshold in Eth (`gwei * 1^dec`). (Ex: **\<0.00001**)
* Decimals for convenience (default is 18)
* Cron interval to send event about `Average Price`

## Configuration

* **Price Avg (gwei)** (`price_avg`, default: `>25.0`): Average Gas Price threshold
* **Price Max (gwei)** (`price_max`, default: `>250.0`): Max Gas price threshold
* **Price Min (gwei)** (`price_min`, default: `<0.05`): Min Gas price threshold
* **Cost Min (Eth)** (`cost_min`, default: \`\`): Min Cost threshold
* **Cost Max (Eth)** (`cost_max`, default: `>0.1`): Max Cost threshold
* **Decimals** (`dec`, default: `18`): Decimals
* **Cron** (`cron`, default: `10 min`): Periodic Average Gas price events See [common configuration](/common-configurations#cron).
* **Severity** (`severity`, default: `0.15`): Severity See [common configuration](/common-configurations#severity).

<Note>
  Supported networks: evm.
</Note>


# Github Monitor
Source: https://docs.extractor.live/security-monitoring/detectors/github-monitor

Monitors Github repository for participation activity (last week and last month commits)

Monitors Github repository for participation activity (last week and last month commits)

## Functionality

* Path to repository. Only `https://` url supported
* Weekly aggregated commit threshdold
* Monthly aggregated commit threshdold
* Cron expression in Quartz syntax, milliseconds value or seconds/minutes/hours/days interval (e.g. `24 hours`)
  Since participation stat is only at weekly interval, Cron expression should be at day interval

Cron interval will be limited to day interval.

* Use custom provided API Token to access private repositories

## Configuration

* **Repository** (`repo`, default: `None`): Repository url
* **Weekly commits** (`commits_week`, default: `<5`): Weekly commits threshoold
* **Monthly commits** (`commits_month`, default: `<50`): Monthly commits
* **Cron** (`cron`, default: `1 day`): Check Interval See [common configuration](/common-configurations#cron).
* **Github Token** (`api_token`, default: `None`): Github API Token with repo scope
* **Severity** (`severity`, default: `-1`): Severity See [common configuration](/common-configurations#severity).

<Note>
  No specific network configuration required (Any network).
</Note>


# Network Monitor
Source: https://docs.extractor.live/security-monitoring/detectors/network-monitor

Monitors Remote host connectivity / availability with periodic requests

Monitors Remote host connectivity / availability with periodic requests

## Functionality

* Detector sends `type` requests and optionally parses response within specified timeout

* Url (Address) to monitor

* Request type: `GET`, `POST`, `PUT`, `HEAD`, `OPTIONS`, `PING`, `TCP`.

* PING: checks if host is reachable

* TCP: checks if port is reachable

* Cron interval. Refer to [Cron](https://docs.extractor.live/common-configurations#cron) for more details

* Scripts to execute to process response body.

Scripts are executed in the order they are specified. Refer to [Scripts](https://docs.extractor.live/common-configurations#condition-threshold) for more details.

Scripts execution result will be in `result` meta field.

* Request Body (applicable for `HTTP` requests)
* Request Headers
* Max redirects for HTTP request
* Optional `Authorization:` header. This header is added to the list of Headers
* Latency threshold (condition) in milliseconds to receive response.

Refer to [https://docs.extractor.live/](https://docs.extractor.live/) for threshold expression syntax).

Example: `>1000`

* Score condition if Scripts return score. If condition is not matched, Alert is not generated.

If `score` is empty, score is not verified. Refer to [Score](https://docs.extractor.live/common-configurations#condition-threshold) for more details

* Generate Alerts on Errors (in Script execution)
* Alert on every Error. If `unchecked`, only new unique Errors will be alerted and duplicates will be omitted
* Description template for the Alert description. Can use any meta field as placeholder (e.g. `{result}`)

## Configuration

* **Cron** (`cron`, default: `10 min`): Cron expression See [common configuration](/common-configurations#cron).
* **Url** (`url`, default: \`\`): Url to monitor
* **Request type** (`type`, default: `GET`): Request type
* **Request Body** (`body`, default: \`\`): Request Body
* **Headers** (`headers`, default: `None`): Request Headers
* **Max redirects** (`redirects`, default: `2`): Max redirects
* **Authorization header** (`auth`, default: \`\`): Authorization header
* **Scripts** (`script`, default: `[]`): Scripts to execute
* **Track Successful** (`track_ok`, default: `True`): Track Successful Responses as Alerts
* **Track Errors** (`track_err`, default: `True`): Track Errors as Alerts
* **Track Error (always)** (`err_always`, default: `True`): Always Alert on Error
* **Score** (`score`, default: \`\`): Score condition
* **Latency (msec)** (`latency`, default: `>1000`): Response latency threshold (msec)
* **Description** (`desc`, default: `{status} {err}`): Description
* **Severity** (`severity`, default: `-1`): Severity See [common configuration](/common-configurations#severity).

<Note>
  No specific network configuration required (Any network).
</Note>


# NIST Alerts Monitor
Source: https://docs.extractor.live/security-monitoring/detectors/nist-alerts-monitor

Detector monitors CVE Alert notifications Monitor watches new or updated CVE records with NIST NVD enrichment for old or incomplete records

Detector monitors CVE Alert notifications
Monitor watches new or updated CVE records with NIST NVD enrichment for old or incomplete records

## Functionality

* Regexp for `description` field  match.

If empty, any description will match

Expression example: `'(?i).*keycloak.*`

* CVE score filter in range `0` to `10`
* Cron when to check CVE records.

Records are updated approximately every 7 minutes, so cron expression will be limited to minimal 7 minutes interval

Detector will cache previous CVE results. (Example: "0 0/1 \* 1/1 \* ? \*")

## Configuration

* **Score** (`score`, default: `7.5`): CVE Score filter
* **Domain** (`domain`, default: \`\`): Regexp match for CVE description
* **Cron** (`cron`, default: `7 min`): CVE Score filter See [common configuration](/common-configurations#cron).
* **Severity** (`severity`, default: `-1`): Severity See [common configuration](/common-configurations#severity).

<Note>
  No specific network configuration required (Any network).
</Note>


# Safe Multisig Monitor
Source: https://docs.extractor.live/security-monitoring/detectors/safe-multisig-monitor

The Safe Multisig Monitor is a detector that monitors the signers of a Safe Multisig contract and alerts if a signer signes a tx data that differs from the other signers.

The Safe Multisig Monitor is a detector that monitors the signers of a Safe Multisig contract and alerts if a signer signes a tx data that differs from the other signers.

## Functionality

* This is a monitoring service that tracks activities related to a Safe Multisig contract, including signer changes, transaction executions, and confirmation submissions.
* The monitor continuously fetches data from the Safe Multisig contract and triggers events when:
* A new signer is detected.
* A transaction is executed after reaching the required threshold of confirmations.
* A signer submits a confirmation for a pending transaction.
* A submitted Safe transaction hash does not match the expected computed hash.
* A transaction signature does not match the expected signer.
* The monitor generates three types of events:
* Safe Multisig Signer - Triggered when the list of signers is retrieved.
* Safe Multisig Transaction - Triggered when a transaction is fully confirmed and executed.
* Safe Multisig Confirmation - Triggered when a signer submits a confirmation for a pending transaction.
* Safe Multisig Safe Tx Hash Mismatch - Triggered when a submitted Safe transaction hash does not match the expected computed hash.
* Safe Multisig Signature Mismatch - Triggered when a submitted signature does not match the expected signer.
* Safe Multisig Simulation - Triggered when a new transaction is created on Safe.
* * It computes the Safe transaction hash and compares it to the submitted hash to ensure it has not been tampered with.
* It validates the signatures provided for each transaction to ensure authenticity.
* It logs detected mismatches and alerts users when discrepancies occur.

## Configuration

* **Severity** (`severity`, default: `0.5`): Severity See [common configuration](/common-configurations#severity).

<Note>
  Supported networks: ethereum, bsc, polygon, optimism, ethereum\_sepolia, avalanche, base, arbitrum.
</Note>


# Security Sleuth
Source: https://docs.extractor.live/security-monitoring/detectors/security-sleuth

Monitors Twitter for security sentiment (Attack and Exploits)

Monitors Twitter for security sentiment (Attack and Exploits)

## Functionality

* Listens to a set of Channels and analizes them for security incidents with LLM

Currently supported: Sources (**Twitter**), LLM (**OpenAI**)

* Channels are additional Twitter accounts (channels) to the predefined list of security information sources
* Anchor is a text filter before sentiment analysis to target specific content (For example, messages often have headers or titles). This allows to improve true positives content for analysis
* Security question to analyze channel messages

## Configuration

* **Cron** (`cron`, default: `10 min`): Cron expression See [common configuration](/common-configurations#cron).
* **Question** (`question`, default: \`\`): Global Question (if empty default question will be used)
* **Channels** (`channels`, default: `None`): Additional Twitter channels (authors)
* **Score** (`score`, default: `0.85`): Sentiment Score
* **Severity** (`severity`, default: `-1`): Severity See [common configuration](/common-configurations#severity).

<Note>
  No specific network configuration required (Any network).
</Note>


# SSL Monitor
Source: https://docs.extractor.live/security-monitoring/detectors/ssl-monitor

Monitors SSL certificate

Monitors SSL certificate

## Functionality

* Detectors downloads SSL certificate and checks it for validity and trust.

**Vadlidity**:

* CA chain is valid
* SSL is not expired
* Signature is correct

**Trust**:

* System CA trusts certificate (self-signed certificates are not trusted by default)
* Domain/Subdomain which SSL certificate to be checked.
* Cron expression in Quartz syntax (ex:  `0 0 0/1 1/1 * ? *` - every hour), frequency in milliseconds or expression (e.g. `1 hour`)

## Configuration

* **Cron** (`cron`, default: `10 min`): Cron expression to check DNS See [common configuration](/common-configurations#cron).
* **Domain** (`domain`, default: \`\`): Domain to monitor
* **Expiry Alert** (`expiry_alert`, default: \`\`): The date when to start alerting about expriration
* **Severity** (`severity`, default: `-1`): Severity See [common configuration](/common-configurations#severity).

<Note>
  No specific network configuration required (Any network).
</Note>


# Security Monitoring
Source: https://docs.extractor.live/security-monitoring/intro

Real-time Hacken Extractor protection for smart contracts and wallets against on-chain attacks, unauthorized changes, and suspicious activity.

Enhance your address's security with advanced Security Monitoring. It constantly watches your blockchain and key security parameters to safeguard your smart contracts from potential attacks, unauthorized ownership changes, contract upgrades, and suspicious interactions.

<Info>
  Security Monitoring activates automatically the moment you add an address — no extra configuration required.
</Info>

## What it detects

<CardGroup>
  <Card title="Address Poison" icon="skull-crossbones" href="/security-monitoring/detectors/address-poison">
    Detects transaction history poisoning with look-alike addresses.
  </Card>

  <Card title="Block Anomaly" icon="cube" href="/security-monitoring/detectors/block-anomaly">
    Monitors blocks for unusual transaction counts, gas, or block size.
  </Card>
</CardGroup>

## How alerts work

When a detector fires, you receive a real-time alert with:

| Field | Description |
| - | - |
| **Severity** | Critical · High · Medium · Low · Info |
| **Contract** | The monitored address that triggered the alert |
| **Detector** | Which detector fired and its configuration |
| **Metadata** | Contextual data specific to the detector type |

<Warning>
  This feature is currently in testing mode. If you encounter inaccurate data or false positives, please contact us at [support@hacken.io](mailto:support@hacken.io).
</Warning>


# Action Details
Source: https://docs.extractor.live/smart-contract-actions/action-details

View and manage the configuration, monitoring status, and execution history of a single smart contract action inside the Hacken Extractor app.

The **Action Detail** page opens when you select **View Details** from the action row menu on the [Actions tab](/smart-contract-actions/actions-overview). It shows the full configuration of a single action and its execution history.

## Configuration fields

| Field | Description |
| - | - |
| **Creation date** | When the action was first created. |
| **Monitoring** | Toggle between `ENABLED` (action fires automatically on trigger) and `DISABLED` (action is paused). |
| **Gas price** | The gas price in gwei used when submitting the transaction. |
| **Gas limit** | The maximum gas units the transaction is allowed to consume. |
| **Gas Tip** | An optional priority fee (EIP-1559) added on top of the base gas price to speed up inclusion. |
| **Value** | The amount of native token (e.g., ETH) to send along with the transaction. Set to `0` for most contract calls. |
| **Function** | The contract function that will be called, shown as `functionName() returnType` (e.g., `pause() void`, `decimals() uint8`). |

<Tip>
  Set **Monitoring** to `DISABLED` to temporarily pause an action without deleting it. Re-enable it when you're ready to resume automatic execution.
</Tip>

***

## Action History

The **Action History** section below the configuration shows every execution of this specific action.

### Filters

| Filter | Description |
| - | - |
| **Severity** | Filter by the severity of the event that triggered the execution: Any, Critical, High, Medium, Low, Info. |
| **Date range** | Narrow results to a specific time period. |
| **UTC Timezone** | Toggle to display timestamps in UTC instead of local time. |
| **Refresh** | Manually reload the history. |

### Columns

| Column | Description |
| - | - |
| **Name** | The name of the action (same for all rows on this page). |
| **Severity** | Severity level of the monitoring event that triggered this execution. |
| **Tx Value** | Value sent in the transaction. |
| **Date and time** | When the transaction was executed. |
| **UID** | Unique identifier for the execution record. |


# Connect an Action Provider
Source: https://docs.extractor.live/smart-contract-actions/action-providers/connect-action-provider

Grant an Action Provider the on-chain permissions it needs to execute functions on your smart contract — wiring up a wallet as an automated signer.

An Action Provider can only execute transactions on a smart contract if it has been explicitly granted a role on that contract. This is a one-time on-chain setup.

## Steps

<Steps>
  <Step title="Copy the Action Provider address">
    Go to **Action Providers**, click on the provider you want to connect, and copy its address using the **Copy** icon next to the address.

    <Tip>
      You can also click the external link icon to view the address on a block explorer.
    </Tip>
  </Step>

  <Step title="Grant the required role on your contract">
    Using your contract's admin interface (e.g., Etherscan, your own frontend, or a script), call the function that grants a role to the provider's address.

    Common roles depending on your contract:

    * `grantRole(PAUSER_ROLE, <provider_address>)`
    * `grantRole(OPERATOR_ROLE, <provider_address>)`
    * `addPauser(<provider_address>)`

    <Warning>
      Do **not** grant `OWNER_ROLE` or equivalent. This would give the provider (and Extractor) full administrative control over your contract. Use only the minimum permissions required for the actions you want to automate.
    </Warning>
  </Step>

  <Step title="Verify the connected actions">
    Back in Extractor, open the provider's detail page and click the **Connected actions** tab. Actions that use this provider will appear here once configured.
  </Step>
</Steps>

## What's next

Now that the provider has the right on-chain permissions, make sure it has enough balance to pay for gas:

* [Deposit funds into the provider](/smart-contract-actions/action-providers/deposit)


# Create an Action Provider
Source: https://docs.extractor.live/smart-contract-actions/action-providers/create-action-provider

Step-by-step guide to registering a blockchain wallet as an Action Provider in Hacken Extractor — the signer that executes smart contract actions.

## Steps

<Steps>
  <Step title="Open Action Providers">
    In the left sidebar, click **Action Providers**. Then click **Add Provider** in the top-right corner.
  </Step>

  <Step title="Select a network">
    In the **Network** dropdown, choose the blockchain network where your smart contract is deployed.

    Available networks:

    * Ethereum
    * BSC
    * Arbitrum One
    * Optimism
    * Gnosis
    * Polygon Mainnet
    * Polygon Amoy
    * Fantom Opera
    * Avalanche (C-Net)
  </Step>

  <Step title="Enter a provider name">
    In the **Provider name** field, enter a descriptive label (e.g., `Mainnet Pauser`). This name is only used within Extractor for identification.
  </Step>

  <Step title="Configure options (optional)">
    Expand the **Options** section to set advanced parameters:

    | Field | Description |
    | - | - |
    | **Tags** | Free-form labels for organizing providers (e.g., `production`, `staging`). |
    | **Type** | **Default** — uses a private key you provide. **HSM** — uses a Hardware Security Module for key storage. |
    | **Private Key** | *(Optional)* Your wallet's private key. If left empty, Extractor will automatically generate a new wallet for you. This value is encrypted and stored securely. |

    <Warning>
      Never use a wallet that holds user funds or has Owner-level permissions as an Action Provider. Create a dedicated wallet with only the minimum permissions needed.
    </Warning>
  </Step>

  <Step title="Save">
    Click **Save**. The provider will appear in the sidebar under **Action Providers** and on the main list.
  </Step>
</Steps>

## What's next

After creating a provider you need to:

1. [Grant it access to your contract](/smart-contract-actions/action-providers/connect-action-provider) — so it can call contract functions.
2. [Deposit gas funds](/smart-contract-actions/action-providers/deposit) — so it can pay for transactions.


# Deposit Funds
Source: https://docs.extractor.live/smart-contract-actions/action-providers/deposit

Fund a Hacken Extractor Action Provider with native tokens so it can pay gas fees when executing automated smart contract transactions on your behalf.

An Action Provider must hold a native token balance on its network to pay gas fees. Without funds, configured actions will fail to execute.

## Steps

<Steps>
  <Step title="Open the provider">
    In the left sidebar, click **Action Providers**, then click on the provider you want to fund.
  </Step>

  <Step title="Click Deposit">
    On the provider detail page, click the **Deposit** button in the top-right area.
  </Step>

  <Step title="Send funds to the deposit address">
    A deposit address (and QR code) will be shown. Transfer the desired amount of native tokens to that address from any external wallet.

    <Info>
      The required amount depends on the gas price of the target network and how often your actions are expected to trigger. You can see an estimated gas cost during smart contract action setup.
    </Info>
  </Step>

  <Step title="Confirm the balance">
    After the transfer is confirmed on-chain, click **Refresh** on the provider detail page. The updated balance will appear under the provider name.
  </Step>
</Steps>

## Tips

* Monitor your provider balance regularly, especially for high-frequency actions or on networks with volatile gas prices.
* Use the **Refresh** button on the provider detail page to manually update the displayed balance at any time.
* If a balance runs low, actions may fail. Extractor will show this in the **Transaction history** tab with a failed status.


# Action Providers
Source: https://docs.extractor.live/smart-contract-actions/action-providers/index

Action Providers connect a blockchain wallet to Extractor so it can execute smart contract actions and cover transaction gas fees.

An **Action Provider** is a blockchain wallet registered in Extractor that can:

* Execute smart contract functions (e.g., pause, emergency withdrawal) triggered by monitoring events
* Cover the gas fees required for those transactions

Each provider is tied to a specific network and holds a native balance that gets consumed as gas. You can have multiple providers across different networks.

## Prerequisites

Before an Action Provider can execute transactions on a contract, two conditions must be met:

<CardGroup>
  <Card title="Grant contract access" icon="key">
    The Action Provider's address must be given an appropriate role on your smart contract (e.g., Pauser, Operator). Never grant Owner-level permissions.
  </Card>

  <Card title="Fund the provider" icon="coins">
    The provider must hold enough native tokens to pay for gas fees on the target network.
  </Card>
</CardGroup>

## Supported Networks

Action Providers can be created on the following networks:

| Network | Native Token |
| - | - |
| Ethereum | ETH |
| BSC | BNB |
| Arbitrum One | ETH |
| Optimism | ETH |
| Gnosis | xDAI |
| Polygon Mainnet | POL |
| Polygon Amoy | POL |
| Fantom Opera | FTM |
| Avalanche (C-Net) | AVAX |

## Provider Types

| Type | Description |
| - | - |
| **Default** | Standard private key–based provider. You can supply your own private key, or leave it blank and Extractor will generate a new wallet for you. |
| **HSM** | Hardware Security Module–based provider for teams that require enterprise-grade key management. |

## Next Steps

<CardGroup>
  <Card title="Create an Action Provider" icon="plus" href="/smart-contract-actions/action-providers/create-action-provider">
    Register a new wallet as an Action Provider
  </Card>

  <Card title="Connect to a Contract" icon="link" href="/smart-contract-actions/action-providers/connect-action-provider">
    Grant the provider permission to call your contract
  </Card>

  <Card title="Deposit Funds" icon="arrow-down-to-line" href="/smart-contract-actions/action-providers/deposit">
    Fund the provider to cover gas fees
  </Card>

  <Card title="Withdraw Funds" icon="arrow-up-from-line" href="/smart-contract-actions/action-providers/withdraw">
    Withdraw remaining balance from a provider
  </Card>
</CardGroup>


# Provider Details
Source: https://docs.extractor.live/smart-contract-actions/action-providers/provider-details

Understand the Action Provider detail view — transaction history, connected actions, deposit balance, and management options for the signing wallet.

Clicking on any provider in the Action Providers list opens its detail page. This page shows the provider's current state and full activity history.

## Header

The header displays the provider's core information:

| Field | Description |
| - | - |
| **Name** | The label you assigned when creating the provider. |
| **Network** | The blockchain network this provider is registered on. |
| **Type** | `pk` (Default — private key provided or auto-generated by Extractor) or `HSM`. |
| **Address** | The wallet address. Use the **Copy** icon or click the external link to view it on a block explorer. |
| **Balance** | Current native token balance available for gas fees. |

The header also contains three action buttons:

| Button | Description |
| - | - |
| **Deposit** | Add native tokens to the provider's balance. |
| **Withdraw** | Send the remaining balance to an external wallet. |
| **Refresh** | Reload the balance from the chain. |

Clicking **···** (more options) reveals:

* **Edit Provider** — update the provider name, tags, or type.
* **Delete Provider** — permanently remove the provider.

<Warning>
  Deleting a provider does not automatically disconnect it from any contracts or remove configured actions. Make sure to update your contract permissions and action configurations before deleting.
</Warning>

***

## Transaction History tab

The **Transaction history** tab shows all transactions executed by this provider, including automated actions triggered by monitoring events and manual executions.

### Filters

| Filter | Description |
| - | - |
| **Severity** | Filter by alert severity: Any, Critical, High, Medium, Low, or Info. The count badge shows the number of transactions at each level. |
| **Date range** | Narrow results to a specific time window. |
| **UTC Timezone** | Toggle to display timestamps in UTC instead of local time. |

### Columns

| Column | Description |
| - | - |
| **Name** | The name of the smart contract action that was executed. |
| **Severity** | Severity level of the monitoring event that triggered the action. |
| **Tx Value** | Value transferred in the transaction (native token). |
| **Date and time** | Timestamp of the transaction. |
| **UID** | Unique identifier for the transaction record. |

***

## Connected Actions tab

The **Connected actions** tab lists all smart contract actions currently configured to use this provider.

### Columns

| Column | Description |
| - | - |
| **Name** | The name of the configured action. |
| **Last updated** | When the action configuration was last modified. |
| **Status** | Whether the action is active, paused, or errored. |
| **Gas price** | The gas price setting used for this action's transactions. |
| **Gas limit** | The maximum gas units allowed per transaction for this action. |

<Tip>
  If you see "You have no actions yet", go to [Set up a Smart Contract Action](/smart-contract-actions/setup-action) to create one and link it to this provider.
</Tip>


# Withdraw Funds
Source: https://docs.extractor.live/smart-contract-actions/action-providers/withdraw

Withdraw the remaining native token balance from an Action Provider back to your own wallet when retiring or rebalancing an automated signer.

You can withdraw the remaining balance from an Action Provider at any time — for example, when decommissioning a provider or rebalancing funds.

## Steps

<Steps>
  <Step title="Open the provider">
    In the left sidebar, click **Action Providers**, then click on the provider you want to withdraw from.
  </Step>

  <Step title="Click Withdraw">
    On the provider detail page, click the **Withdraw** button in the top-right area.
  </Step>

  <Step title="Fill in withdrawal details">
    In the withdrawal form, enter:

    | Field | Description |
    | - | - |
    | **Address** | The destination wallet address to receive the funds. |
    | **Amount** | The amount of native tokens to withdraw. |
    | **Gas tip** *(optional)* | An additional miner tip (EIP-1559 networks) to prioritize the withdrawal transaction. |
  </Step>

  <Step title="Confirm withdrawal">
    Click **Withdraw** to submit the transaction. The funds will be sent on-chain to the destination address.
  </Step>
</Steps>

<Warning>
  Make sure you control the destination address before submitting. Blockchain transactions are irreversible.
</Warning>


# Actions overview
Source: https://docs.extractor.live/smart-contract-actions/actions-overview

The Actions page for a monitored contract — view, manage, and track smart contract actions and their execution history across your portfolio.

The **Actions** page is accessible from within any monitored entity (contract) in the sidebar under **Actions**. It lets you manage the smart contract actions configured for that specific contract and review their execution history.

## Page header

The header shows the monitored contract's name, address, and two top-level controls:

| Control | Description |
| - | - |
| **Add Action Provider** | Opens the Create Provider modal to register a new wallet as an Action Provider for this contract's network. |
| **Entity Settings** | Opens the configuration settings for the monitored entity. |

***

## Executions tab

The **Executions** tab shows a log of every transaction that has been executed by an Action Provider for this contract.

### Filters

| Filter | Description |
| - | - |
| **Severity** | Filter executions by the severity of the monitoring event that triggered them: Any Severity, Critical, High, Medium, Low, or Info. |
| **Date range** | Narrow results to a specific time period. |
| **UTC Timezone** | Toggle to display timestamps in UTC instead of local time. |
| **Refresh** | Manually reload the execution list. |

### Columns

| Column | Description |
| - | - |
| **Name** | The name of the action that was executed. |
| **Severity** | Severity level of the event that triggered the execution. |
| **Tx Value** | Value transferred in the transaction. |
| **Date and time** | Timestamp of the execution. |
| **UID** | Unique identifier for the execution record. |

***

## Actions tab

The **Actions** tab lists all smart contract actions configured for this entity.

### Linked vs. Unlinked Actions

An action becomes **linked** when there is an Action Provider on the same network as the contract. If no matching provider exists, actions appear in the **Unlinked Actions** section and will not execute automatically until a compatible provider is added.

<Warning>
  If you see the "Prevent Fund Losses with Actions" prompt, it means no Action Provider has been created for this contract's network. Click **Add Action Provider** to create one.
</Warning>

### Actions table columns

| Column | Description |
| - | - |
| **Name** | The name you assigned to the action. |
| **Last updated** | When the action configuration was last modified. |
| **Status** | `ENABLED` — the action will trigger automatically. `DISABLED` — the action is paused and will not execute. |
| **Gas price** | The gas price (in gwei) configured for this action's transactions. |
| **Gas limit** | The maximum gas units allowed per transaction. |

### Row menu (···)

Each action row has a **···** menu with:

| Option | Description |
| - | - |
| **View Details** | Opens the [Action Detail](#) page for full configuration and history. |
| **Delete Action** | Permanently removes the action. |


# Smart Contract Actions
Source: https://docs.extractor.live/smart-contract-actions/intro

Set up administrative smart contract actions in Hacken Extractor that execute automatically in response to monitoring events — pause, revoke, or rebalance.

This feature allows you to set up administrative smart contract actions, such as contract pausing or emergency withdrawals, which can be executed in response to monitoring events.

You can access a list of available contract functions and set up Contract Actions, which means specifying the function call with predefined parameters.

These Contract Actions can be executed manually or set to execute automatically in response to specific monitoring events detected by the Hacken Extractor.


# Create an Action
Source: https://docs.extractor.live/smart-contract-actions/setup-action

Create a smart contract action that executes automatically in response to Hacken Extractor monitoring events, or manually on demand from the dashboard.

A **Smart Contract Action** defines a specific contract function call that Extractor can trigger automatically when a monitoring event fires, or that you can run manually at any time.

## Prerequisites

Before creating an action:

1. An [Action Provider](/smart-contract-actions/action-providers/create-action-provider) must exist on the **same network** as the contract.
2. The provider must have been [granted the required role](/smart-contract-actions/action-providers/connect-action-provider) on your contract.
3. The provider must have [sufficient balance](/smart-contract-actions/action-providers/deposit) to pay gas fees.

## Create an action

<Steps>
  <Step title="Open the Actions tab">
    In the left sidebar, navigate to your monitored contract and click **Actions**. Then click **Create Action**.
  </Step>

  <Step title="Enter a name">
    Give the action a descriptive name (e.g., `Pause Contract`, `Emergency Withdraw`).
  </Step>

  <Step title="Select the contract function">
    In the **Function** dropdown, choose the function you want to execute. Functions are loaded from the contract's ABI and shown in the format `functionName() returnType`.
  </Step>

  <Step title="Choose a trigger and/or detector (optional)">
    Select a **trigger** and/or a **detector** that should automatically fire this action when an event is detected.

    * **Trigger** — fires the action based on on-chain conditions (e.g., a specific function call, ERC-20 transfer, failed transaction).
    * **Detector** — fires the action based on on-chain or off-chain signals (e.g., price drop, AML alert, balance threshold, contract hash change).

    Both can be selected together. If left empty, the action can only be run manually.
  </Step>

  <Step title="Configure gas settings (optional)">
    | Field | Description |
    | - | - |
    | **Gas price** | Override the network's default gas price (in gwei). Leave blank to use market values. |
    | **Gas limit** | Maximum gas units for the transaction. Leave blank to use the estimated value. |
    | **Gas Tip** | Priority fee for EIP-1559 networks to speed up transaction inclusion. |
    | **Value** | Amount of native token to send with the call (usually `0`). |
  </Step>

  <Step title="Save">
    Click **Create Action**. The action appears in the Actions tab with status `ENABLED`.
  </Step>
</Steps>

<Info>
  The action will execute automatically when the selected trigger fires **and** the linked Action Provider has enough balance to cover gas. If no provider is linked for the contract's network, the action will appear as **Unlinked** and will not run until a matching provider is added.
</Info>

***

## Enable / Disable an action

Open the action's [detail page](/smart-contract-actions/action-details) and use the **Monitoring** dropdown to switch between `ENABLED` and `DISABLED`. Disabling pauses automatic execution without deleting the action.

***

## Run an action manually

You can trigger any action on demand, regardless of monitoring events.

<Steps>
  <Step title="Open the action row menu">
    On the Actions tab, find the action and click **···** → **View Details**, then use the **Run Manually** option. Alternatively, click the run icon directly in the action row.
  </Step>

  <Step title="Configure the manual run">
    | Field | Description |
    | - | - |
    | **Severity** | Severity label to attach to this manual execution (default: Info). |
    | **Alert message** | Custom message for the execution log (defaults to the detector/trigger message). |
    | **Gas price** | Override gas price for this run only (defaults to market value). |
    | **Gas limit** | Override gas limit for this run only. |
  </Step>

  <Step title="Click Run">
    Click **Run** to submit the transaction. The execution will appear in the **Executions** tab and the action's **Action History**.
  </Step>
</Steps>

***

## Delete an action

On the Actions tab, click **···** → **Delete Action** on the action row. This permanently removes the action and cannot be undone.


# Supported Networks
Source: https://docs.extractor.live/supported-networks

Catalog of EVM-compatible and non-EVM blockchain networks supported by Hacken Extractor for monitoring smart contracts, wallets, and DeFi protocols.

Hacken Extractor supports real-time monitoring across all networks listed below. New chains are added regularly.

## EVM-Compatible

<CardGroup>
  <Card title="Ethereum" icon="https://raw.githubusercontent.com/trustwallet/assets/master/blockchains/ethereum/info/logo.png" />

  <Card title="Arbitrum One" icon="https://raw.githubusercontent.com/trustwallet/assets/master/blockchains/arbitrum/info/logo.png" />

  <Card title="Optimism" icon="https://raw.githubusercontent.com/trustwallet/assets/master/blockchains/optimism/info/logo.png" />

  <Card title="Base" icon="https://raw.githubusercontent.com/trustwallet/assets/master/blockchains/base/info/logo.png" />

  <Card title="Polygon" icon="https://raw.githubusercontent.com/trustwallet/assets/master/blockchains/polygon/info/logo.png" />

  <Card title="Polygon Amoy" icon="https://raw.githubusercontent.com/trustwallet/assets/master/blockchains/polygon/info/logo.png" />

  <Card title="Binance Smart Chain" icon="https://raw.githubusercontent.com/trustwallet/assets/master/blockchains/smartchain/info/logo.png" />

  <Card title="Avalanche" icon="https://raw.githubusercontent.com/trustwallet/assets/master/blockchains/avalanchec/info/logo.png" />

  <Card title="Fantom Opera" icon="https://raw.githubusercontent.com/trustwallet/assets/master/blockchains/fantom/info/logo.png" />

  <Card title="Gnosis" icon="https://raw.githubusercontent.com/trustwallet/assets/master/blockchains/xdai/info/logo.png" />

  <Card title="Linea" icon="https://raw.githubusercontent.com/trustwallet/assets/master/blockchains/linea/info/logo.png" />

  <Card title="Blast" icon="https://raw.githubusercontent.com/trustwallet/assets/master/blockchains/blast/info/logo.png" />

  <Card title="zkSync" icon="https://raw.githubusercontent.com/trustwallet/assets/master/blockchains/zksync/info/logo.png" />

  <Card title="Scroll" icon="https://raw.githubusercontent.com/trustwallet/assets/master/blockchains/scroll/info/logo.png" />

  <Card title="Telos" icon="https://icons.llamao.fi/icons/chains/rsz_telos.jpg" />

  <Card title="ADI" icon="https://icons.llamao.fi/icons/chains/rsz_adi.jpg" />

  <Card title="Ethereum Sepolia" icon="https://raw.githubusercontent.com/trustwallet/assets/master/blockchains/ethereum/info/logo.png" />

  <Card title="Ethereum Holesky" icon="https://raw.githubusercontent.com/trustwallet/assets/master/blockchains/ethereum/info/logo.png" />
</CardGroup>

## Non-EVM

<CardGroup>
  <Card title="Bitcoin" icon="https://raw.githubusercontent.com/trustwallet/assets/master/blockchains/bitcoin/info/logo.png" />

  <Card title="Solana" icon="https://raw.githubusercontent.com/trustwallet/assets/master/blockchains/solana/info/logo.png" />

  <Card title="Tron" icon="https://raw.githubusercontent.com/trustwallet/assets/master/blockchains/tron/info/logo.png" />

  <Card title="Stellar" icon="https://raw.githubusercontent.com/trustwallet/assets/master/blockchains/stellar/info/logo.png" />

  <Card title="VeChain" icon="https://raw.githubusercontent.com/trustwallet/assets/master/blockchains/vechain/info/logo.png" />

  <Card title="ICP" icon="https://icons.llamao.fi/icons/chains/rsz_icp.jpg" />

  <Card title="ZetaChain" icon="https://raw.githubusercontent.com/trustwallet/assets/master/blockchains/zetachain/info/logo.png" />

  <Card title="Somnia" icon="https://icons.llamao.fi/icons/chains/rsz_somnia.jpg" />
</CardGroup>