Skip to main content

Forta

Forta — a reference card for a crypto project: what the product does and how verifiable the project’s key claims are; also — alignment with the Decentralized AI thesis (DecAI Fit).

Forta — a Security | Infra network for monitoring and preventing onchain threats (runtime security): nodes scan transactions/state changes and run detection bots to issue alerts and (in the case of Firewall) block malicious transactions; token (symbol: FORT) on Ethereum (ERC‑20).

Disclaimer

Important: this page is a reference overview of the project. Within DecAIHub, we separately record a verification based on open sources within the AI thesis (what is real AI/onchain/why a token, and which sources this is based on).
This is not financial advice and not a recommendation to buy/sell/hold any asset. We do not assess price, returns, or entry/exit timing.
Conclusions are based on publicly available materials found as of the verification date. The absence of confirmation does not imply the absence of the technology.

TL;DR (for readers who are not into AI)

  • What it is: monitoring and a “firewall” for onchain applications: the system finds suspicious transactions/anomalies in real time and can prevent the execution of risky transactions.
  • Who it’s for: protocol/rollup teams, wallets and services that need risk screening and signals about hacks/scams/compliance.
  • Why onchain/token: onchain is needed for economic security (staking/slashing and network rules), and the FORT token is used for participant staking, payment of data fees and governance (per the documentation).

How it works (very briefly)

  1. The user does: connects Forta Firewall/feeds to their application/rollup or subscribes to alerts.
  2. The system does: scan nodes continuously scan transactions and state changes and run detection bots (agents), which can use, among other things, ML/time‑series analysis to detect anomalies.
  3. The user gets: risk alerts (and/or prevention of malicious transactions at the “screening” level before execution).
  4. Where the blockchain is: staking/slashing and participant parameters are described as onchain mechanics (FORT as a “work token”); the FORT token is ERC‑20 (Ethereum) and is also available on Polygon/Base/Arbitrum.
  5. Token role (if any): FORT is used for staking scan node pools and bots, paying data fees, gas fees on Forta Chain and participation in governance.

Quick links: AI thesis fit

Project passport

Field Value
Project name Forta
Also known as (aliases) Forta Firewall; Forta Network; $FORT
Logo (logo) ../assets/127_forta_logo.png
Token symbol (ticker) FORT
Category Security | Infra
Primary chain (chain) Ethereum
Type EVM
Network status mainnet
Consensus (consensus) PoS (Ethereum)
Launch date (launch_date) 2021 (launch of the protocol/contracts; per the litepaper, “launched in 2021”)
Project status (status) active
Token (standard) ERC-20
Token contract 0x41545f8b9472d758bb669ed8eaeeecd7a9c4ec29
Token model (token_type) utility (staking + fee + governance + gas (FortaChain))
Max supply 1,000,000,000 FORT (capped)
Issuance fixed (cap)
Tokenomics (tokenomics, brief) work‑token model: staking for scan node pools and bots; data fees in FORT; staking on Polygon
Governance governance via FORT (token‑holder voting)
Admins/keys —
Audit yes (Forta Node assessment report)
Bug bounty yes (Immunefi)
Team (team) —
Funding (investors/funding) —
AI component (ai_component) ML anomaly analysis in detection bots
Use‑case (use_case) runtime security (transaction monitoring/screening)
DecAI Fit — AI thesis fit 3/6 — medium alignment with the Decentralized AI thesis
DecAI Fit component summary 1 / 2 / 3 / 3
Last verified 2026-02-11

General project overview

Forta is an onchain security and compliance infrastructure that builds “runtime security” for Web3: a network of independent operators runs scan nodes that continuously analyze transactions/events and execute detection bots (agents). The network’s output is alerts/signals about potential threats (hacks, scams, anomalies, oracle problems, etc.), and in the product form of “Firewall” — also the prevention of risky transactions before their execution.

Per the Tier‑1 litepaper and documentation, the network is designed as a permissionless system with economic security: participants stake FORT, and penalties/slashing are possible for violations. This is meant to reduce the risk of “fake” signals and to incentivize the correct operation of the infrastructure.

Features/modules

  • Forta Firewall: screening/blocking of malicious transactions “before execution” (per the website).
  • Monitoring Network: nodes scan transactions and state changes, execute detection bots and publish alerts.
  • Detection bots (agents): containerized bots with detection logic; the documentation allows the use of ML/time‑series analysis.
  • Staking/slashing: a work‑token model for scan node pools and bots, stake delegation and reward distribution.

Typical scenarios

  • Scenario 1 (risk alerts): a protocol/wallet subscribes to alerts → receives signals about suspicious activity → reacts (pause, blocklist, UI warnings).
  • Scenario 2 (Firewall): a rollup/application connects screening → malicious transactions are blocked before execution (per the product’s claim).
  • Scenario 3 (participation as an operator): an operator launches a scan node pool and stakes FORT → receives rewards while meeting the SLA → risk of slashing for violations.

Getting started (wallet/network)

  • What you need: for use — access to Forta Firewall/feeds; for staking — a wallet and FORT tokens.
  • Network/chain: FORT — ERC‑20 on Ethereum; per the documentation, delegated staking is performed on Polygon (via the staking contract).
  • Fees: Ethereum/Polygon gas (depends on the operation) + possible subscriptions/fees if data plans are purchased (in FORT).

Architecture/tech (non‑AI)

  • Components: scan node software (container supervisor), detection bots (Docker containers), the alerts/subscription layer, onchain contracts for staking/network parameters.
  • Participant roles: bot developers, node/pool operators, stake delegators, data consumers (Firewall/feeds).
  • Where logic runs: analysis of blocks/transactions and execution of bots — offchain (nodes); economic rules/stake — onchain.
  • Dependencies: RPC/full nodes for the chains being scanned; Docker; the Polygon bridge for staking FORT (per the docs).

Token/economics (expanded, no forecasts)

  • Token utility: staking of scan node pools and detection bots; payment of data fees (monthly fee) in FORT; gas fees on Forta Chain; governance.
  • Protocol necessity drivers: work‑token model: the stake serves as economic collateral for quality and can be slashed for malicious behavior.
  • Who pays fees: users/operators pay gas for onchain operations; data consumers pay fees (in FORT) for plans/feeds.
  • Issuance: total supply capped at 1B FORT.
  • Security/incentive mechanisms: delegated staking, rewards, slashing (described in the docs).

Governance

  • Who makes decisions: governance via FORT (voting token holders) — per the token docs/token page.
  • How protocol parameters change: via proposals/votes (the details of the process are outside the scope of this card).

Security and incidents

  • Audits: a security assessment report of the Forta Scan Node has been published (April 2022).
  • Bug bounty: a program on Immunefi (KYC/PoC required; max bounty $8k per the program page).
  • Threat model (notes): part of the “intelligence” lives in offchain nodes and bots (quality depends on operators/bot developers); economic security via stake/slashing is intended to reduce the incentives for malicious behavior.

Project status and timeline

  • Current status: active infrastructure (Forta Firewall/Monitoring Network), public documents and repositories.
  • Key milestones: litepaper (last updated Dec 2021; published Jul 2022); Forta Node audit report (Apr 2022).

Ecosystem/integrations

  • Where it is used: Forta Firewall is positioned for rollups/protocols; the network scans EVM‑compatible chains (per the litepaper).

AI component of the project

  • What is real AI here? The Tier‑1 litepaper and the website allow/claim the use of ML/anomaly analysis inside detection bots (agents) to find threats and anomalies; at the same time, Forta is rather a platform/network for such bots, not “a single model”.
  • What is truly onchain? The FORT token on Ethereum and the onchain staking/delegation contracts (Polygon) as part of the work‑token model and network security.
  • Why is a token needed? FORT is needed for staking scan node pools and bots, paying data fees and governance; the docs also indicate a gas role on Forta Chain.
  • Red flags (based on the information found): AI‑washing risk (no public metrics/description of specific models; AI may be a “capability of the bots” rather than a guaranteed component); onchain‑washing risk (part of the logic and the quality are offchain).

DecAI Fit component summary

  • DecAI Fit: 3/6 — medium alignment with the Decentralized AI thesis
Component Level Score
AI reality low 1
Onchain necessity medium 2
Token necessity high 3
Evidence Tier‑1 present 3
Details

AI reality

AI_0 — AI intent (Tier‑1 roadmap) (1/0)

  • AI_0 (decision): 0
  • Claim (one line): there is a Tier‑1 description of AI/ML approaches in detection bots (see AI_1), so AI_0 is not used.
  • Evidence: Tier‑1 — https://docs.forta.network/en/latest/2022-7-11%20Forta%20Litepaper.pdf
  • Why sufficient / why not (one line): AI_0 applies only when AI_1..AI_4 = 0.
  • Conflict note (if any): —

AI_1 — what the AI does (1/0)

  • AI_1 (decision): 1
  • Claim (one line): detection bots can use ML/time‑series analysis to detect anomalies/threats in transactions and state changes.
  • Evidence: Tier‑1 — https://docs.forta.network/en/latest/2022-7-11%20Forta%20Litepaper.pdf; https://forta.org/
  • Why sufficient / why not (one line): the litepaper directly names ML as a technique for bot detection, and the website claims AI‑powered screening.
  • Conflict note (if any): —

AI_2 — demos/examples (1/0)

  • AI_2 (decision): 0
  • Claim (one line): there are public product pages, but no separate Tier‑1 demo that verifiably demonstrates specifically the AI part (rather than general monitoring/screening).
  • Evidence: Tier‑1 — https://forta.org/
  • Why sufficient / why not (one line): without demos/examples that allow separating “AI” from the rest of the logic, AI_2 = 0.
  • Conflict note (if any): —

AI_3 — metrics/quality (1/0)

  • AI_3 (decision): 0
  • Metrics: —
  • Context (version/date/how measured): —
  • Evidence: Tier‑1 — https://forta.org/
  • Why sufficient / why not (one line): there are no reproducible quality metrics of AI detection in the Tier‑1 sources.
  • Conflict note (if any): —

AI_4 — tech description/architecture/versions (1/0)

  • AI_4 (decision): 0
  • Claim (one line): there is a technical description of the network of bots/nodes, but no description of specific models/versions/architecture of AI modules.
  • Evidence: Tier‑1 — https://docs.forta.network/en/latest/2022-7-11%20Forta%20Litepaper.pdf
  • Why sufficient / why not (one line): the Forta architecture is described, but the AI architecture is not specified → AI_4 = 0.
  • Conflict note (if any): —

Onchain necessity

OC_1 — contracts/addresses/chain (1/0)

  • OC_1 (decision): 1
  • Chain: Ethereum (token); Polygon (staking per the docs)
  • Addresses/identifiers: FORT ERC‑20: 0x41545f8b9472d758bb669ed8eaeeecd7a9c4ec29
  • Evidence: Tier‑1 — https://etherscan.io/token/0x41545f8b9472d758bb669ed8eaeeecd7a9c4ec29; https://docs.forta.network/en/latest/fort-token/
  • Why sufficient / why not (one line): there is an onchain token address + a Tier‑1 description that staking is implemented by a contract on Polygon.
  • Conflict note (if any): —

OC_2 — onchain beyond just a token (1/0)

  • OC_2 (decision): 1
  • What useful logic is onchain: work‑token security model: staking/delegation/slashing for scan node pools and bots; network parameters are recorded/enforced via smart contracts.
  • Evidence: Tier‑1 — https://docs.forta.network/en/latest/fort-token/; https://docs.forta.network/en/latest/delegated-staking-introduction/
  • Why sufficient / why not (one line): Tier‑1 describes onchain staking/slashing rules, i.e. onchain ≠ only the token.
  • Conflict note (if any): —

OC_3 — onchain is critical (1/0)

  • OC_3 (decision): 0
  • “Replace the blockchain” test: transaction monitoring/screening can be imagined as a service without a blockchain as well; Tier‑1 does not prove that a key property of the product breaks down without onchain.
  • Evidence: Tier‑1 — https://forta.org/; https://docs.forta.network/en/latest/fort-token/
  • Why sufficient / why not (one line): onchain is important for economic security, but “criticality” per the replacement test is not proven → OC_3 = 0.
  • Conflict note (if any): —

Token necessity

TK_0 — no token (1/0)

  • TK_0 (decision): 0
  • Claim (one line): the project has a token, FORT (ERC‑20).
  • Evidence: Tier‑1 — https://docs.forta.network/en/latest/fort-token/; https://etherscan.io/token/0x41545f8b9472d758bb669ed8eaeeecd7a9c4ec29
  • Why sufficient / why not (one line): the token exists → TK_0 = 0.
  • Conflict note (if any): —

TK_1..TK_4 (1/0)

TK_1 — payment for the service (1/0)

  • TK_1 (decision): 1
  • Claim (one line): the purchase of data plans/feeds is paid with a monthly fee in FORT (and/or USDC for premium feeds, at the feed owner’s choice).
  • Evidence: Tier‑1 — https://docs.forta.network/en/latest/fort-token/
  • Why sufficient / why not (one line): Tier‑1 directly describes the payment of data fees.
  • Conflict note (if any): —

TK_2 — incentives/collateral/penalties (1/0)

  • TK_2 (decision): 1
  • Claim (one line): scan node pools and detection bots are required to hold a minimum stake of FORT; the stake can be slashed for malicious behavior.
  • Evidence: Tier‑1 — https://docs.forta.network/en/latest/fort-token/; https://docs.forta.network/en/latest/delegated-staking-introduction/
  • Why sufficient / why not (one line): the economic security of the network (stake/slash) is described.
  • Conflict note (if any): —

TK_3 — governance (1/0)

  • TK_3 (decision): 1
  • Claim (one line): FORT holders participate in governance and vote on proposals that affect the evolution of the network.
  • Evidence: Tier‑1 — https://docs.forta.network/en/latest/fort-token/
  • Why sufficient / why not (one line): governance is directly stated as a primary function of the token.
  • Conflict note (if any): —

TK_4 — token is replaceable (1/0)

  • TK_4 (decision): 0
  • Claim (one line): the token is hard to replace without loss of meaning, since it participates in the security bond (stake/slash) and governance.
  • Evidence: Tier‑1 — https://docs.forta.network/en/latest/fort-token/
  • Why sufficient / why not (one line): the utility includes a security bond and governance, which usually requires a native network asset.
  • Conflict note (if any): —

Evidence (table)

Tier Source What it proves
Tier‑1 https://docs.forta.network/en/latest/2022-7-11%20Forta%20Litepaper.pdf Network architecture (nodes + detection bots), the purpose of runtime security; mention of ML as a detection technique for bots.
Tier‑1 https://docs.forta.network/en/latest/fort-token/ Tier‑1 tokenomics/utility of FORT: staking for pools/bots, data fees, gas on Forta Chain, governance.
Tier‑1 https://docs.forta.network/en/latest/delegated-staking-introduction/ Tier‑1 description of delegated staking, reward epochs, slashing risks; the staking contract on Polygon.
Tier‑1 https://etherscan.io/token/0x41545f8b9472d758bb669ed8eaeeecd7a9c4ec29 Onchain fact: the FORT token contract and max total supply of 1B.
Tier‑1 https://forta.org/ Product claims of Forta Firewall/Monitoring: transaction screening “before execution”, AI‑powered positioning.
Tier‑1 https://docs.forta.network/en/latest/2022Q1-V2-FortaNode-AuditReport.pdf Public audit/assessment of the Forta Scan Node (Apr 2022).
Tier‑1 https://immunefi.com/bug-bounty/forta/information/ The Forta Network bug bounty program on Immunefi (terms/max reward/PoC/KYC).
Tier‑1 https://github.com/forta-network/forta-node The source code of the scan node software (Docker supervisor + bots/agents).

No comments to display

Back to top