Forta Network is a real-time monitoring network for blockchain security and operation surveillance. As one of the few decentralized projects in the Web3 monitoring sector, the overall design of Forta is innovative to a certain extent. So far, over $36 billion in TVL is monitored by Forta, which offers runtime monitoring and abnormality detection for blockchains like Ethereum, Avalanche, and Polygon. It is promising in future applications and comes with a good narrative. A $230 million investment round led by a16z had also placed it under the spotlight of the industry.

Investment Brief

From 2009 to 2022, the blockchain industry has experienced 13 years of rapid growth. However, it was also accompanied by countless fund losses caused by hacking, protocol vulnerabilities, private key leakages, and insider jobs. We have seen a total fund loss of more than $510 million in 2020. More distressingly, the fund lost in the first 4 months of 2022 has exceeded that in 2020 and 2021 combined. Since attacking methods have been evolving at pace with the industry’s development, the importance of security cannot be overemphasized. And security is the cornerstone for the Web3 world to grow from billions to trillions of worth. Rather than relying on traditional solutions like routine audits and bug bounties, the whole industry needs a complete set of security standards that are disruptive from perception to practice.

Since the Ethereum mainet went live in 2015, major shifts have happened in the development and security practices of smart contracts — smart contract audits and reusable codebases have become standard practices. Though being helpful for detecting and preventing bugs and vulnerabilities in code, the effectiveness of such methods is often limited. Once deployed on blockchains, smart contracts are out in the water facing variable risks. Uncertainty can be easily increased by contract governance, interactions among contracts, and market incidence. In other words, smart contracts may encounter problems while the code is running properly. The security of smart contracts requires continuous efforts.

In general, developers would not actively discover all logical vulnerabilities in their code — a fair amount of them are reported by users after the program goes live. To exploit such vulnerabilities, hackers may need to initiate multiple abnormal transactions. Monitoring systems can send out alerts when they detect early signs of a series of abnormal transactions. In this way, they can help prevent huge fund losses and indicate fixes for the vulnerability. Therefore, monitoring systems are essential in the Web3 world.

Most of the current monitoring solutions are based on centralized systems. A drawback of centralized monitoring systems is that their speed cannot keep up with newly deployed smart contracts. When the scale of a decentralized open-sourced project reaches a tipping point, its growth will become too fast for a centralized monitoring solution to cover. In order to solve this problem, Forta uses a decentralized and incentivized monitoring system, which ensures efficient and complete deployment of smart contract monitoring in no time.

After a test network phase (Fortification), now Forta has launched officially and is running in good condition. While in the Fortification Phase, it was able to detect a flash loan-assisted-price-manipulation attack on InverseFinance and send out alerts. However, there are a few things that we need to be cautious about in this project:

1. The current detection bots have few alert templates. Although it alerted the attack on InverseFinance, the alerts only mentioned high volume ETH transfer rather than token price fluctuation. And developers tend to neglect alerts like that.
2. Although the weekly incentive of $FORT tokens is issued in a stable amount, the incentive portions for different blockchains are still allocated by the team.
3. The $FORT token needs to be more empowered. Now it is only used for node runner staking and detection bot signaling. Subscribers can still use Forta’s monitoring service for free.
4. The bot development incentives of Forta Network are donated by Forta Foundation so far. Hence, the incentive advantage of a decentralized system is not fully utilized.

1. Overview

1.1 Project Introduction

Forta Network is a decentralized real-time security and monitoring system for blockchains. It is applied to monitor the threats and abnormalities on DeFi, NFT, governance, cross-chain bridges, and other Web3 systems. By providing timely and useful information on system security and stability, it can inform contract owners to take defensive and remedial actions in time and minimize their losses.

Forta Network applies a permissionless and decentralized model for incentivization. It issues the $FORT token to attract node providers and detection bot developers, whose contributions help Forta build a real-time, complete, easy-to-use monitoring system with wide coverage. Using the provided detection bot templates, contract developers can monitor abnormalities effortlessly — they don’t even need to write any code. Or they can use the Forta SDK to create detection bots for customized monitoring. Forta Network also supports notification webhooks, with which contract devs can deploy automated abnormality defense.

Forta Network is exceptional in that it provides modularized, standardized, and no-code monitoring for smart contracts. Contract devs don’t need to spend so much effort on building a standalone monitoring system, so they can focus on the deployment of the defense measures. It makes Web3 a much safer world while protecting countless user assets.

Currently, Forta Network is monitoring multiple blockchains including Ethereum, Avalanche, and Polygon. It is also in cooperation with Dapps like Lido, Compound, MakerDAO, dYdX, and Balancer to project their users’ assets.

1.2 Basic Information

2. Project Details

2.1 The Team

Forta Network was developed by an innovation subdivision of OpenZeppelin. So far they haven’t revealed too much information on its team members, but from its core GitHub projects, forta-core-go and forta-node, we can see that most of the commits are from members of OpenZeppelin or previous contributors of OpenZeppelin. So we can assume that Forta is a spin-off team of OpenZeppelin; its members actually work for OpenZeppelin. A piece of publicly available information is that the CTO of OpenZeppelin, Jonathan Alexander, is a co-founder of Forta.

OpenZeppelin built one of the most widespread contract codebases on EVM. Most ERC-20, ERC-721, and ERC-1155 tokens are created with OpenZeppelin’s no-code or low-code development tools. OpenZeppelin is also in close partnership with famous projects and companies including AAVE, Ethereum Foundation, Coinbase, and The Graph.

Jonathan Alexander, the co-founder of Forta Network, is also the CTO of OpenZeppelin. He graduated from UCLA in 1984. From April 2010 to March 2016, he served Vonage (the largest VoIP provider in the US) as its CTO, mainly responsible for its cloud communication infrastructure. From March 2016 to March 2020, he became the CTO of QASymphony/Tricentis (the two software testing companies merged in 2018). In April 2020, he joined OpenZeppelin as its CTO.

According to the resume of Jonathan Alexander, we can see he is experienced with software management and infrastructure building, which align with the technical product positioning of Forta. And under his leadership, both of his ex-employers had gained rapid growth from under $5 million to over $100 million.

Backed by the industry leader OpenZeppelin and an outstanding seed round, Forta has built its own presence in the Web3 world. As the standard setter and auditor for Ethereum codebases, OpenZeppelin has demonstrated its development prowess. We believe Forta will bring an even better experience to its users in the future.

2.2 Fundraising

2.3 Codebase and SDK

Most of Forta’s GitHub contributors are members of OpenZeppelin. From the quality of OpenZeppelin’s open-source projects, we can see Forta has a fairly high standard on its developers.

The project forta-node is the software used by Forta Network node providers. After precompilation, the created docker mirrors will be running in the servers of providers — its code is not user-facing. Besides having complete unit testing, the project also runs performance testing to prevent server overload. However, it still has several bug issues that are not closed yet, including the issue on July 20th reporting the auto-update schedule of v0.5.1 didn’t work. And some discarded issues in the kanban view are not closed either. Such issues reveal the negligence in the project management of a small team.

The project forta-bot-sdk is the developer kit Forta Network uses to program detection bots. It includes two modules — cli and sdk. The project is mainly oriented to JavaScript/TypeScript and Python developers, who need to refer to its SDK for development. Since its code is user-facing, the documentation and changelogs of the project are more complete. But its unit testing has inadequate coverage on use cases — it only covers the cli module, not the sdk. One of its issues indicates that the project was planning on adding Golang and Rust versions this April. But those versions are not launched yet for a possible lack of development capacity. And some of its inactive issues are not closed for a long time.

To sum up, as the largest open-source codebase provider on EVM, OpenZeppelin boasts of its development quality and guaranteed development cycle and usability. A blemish of the Forta project is its loose project management, but that doesn’t affect the quality of the overall project.

2.4 Technical Details

The operation of Forta Network is supported by two modules and three roles. To understand the mechanism of the network, we need to figure out these two modules and three roles.

2.4.1 Two Modules

There are two modules in Forta Network: detection bots and scan nodes.

Detection bots: They are logical scripts that are used to look up certain transaction characteristics or status changes on smart contracts of supported chains (e.g. abnormality detection). To put it in simple words, detection bots are like security cameras that monitor blockchains. Developers can program the bots with certain conditions to monitor specific content, e.g. changes in contract governance, updates of a key contract setup, abnormal operations in an API call to a contract, etc. The bots can also be used to monitor the specific statuses of blockchains. Such statuses could be the price changes of a token in oracles, abnormal transaction volumes of a token, or a bulk decrease/increase in the balance of all accounts in a network. Bot developers can even apply machine learning models to predict and preempt attacking behaviors. Now Forta already supports no-code creation of detection bots. Users can set up monitoring conditions for most smart contracts without writing any code.

Scan nodes: They are used to scan all transaction data of each block in a designated blockchain. We can consider they are detection bot operators that access data from a target blockchain for the bots. When detection bots in a scan node find features that match certain conditions or events, they will send alerts to the network. Such alerts will be stored in IPFS. And anyone can subscribe to such alerts with Forta Explorer or API.

2.4.2 Three Roles

There are three roles in Forta Network: alert subscribers, detection bot developers, and scan node providers.

Alert subscribers: Anyone can use Forta to monitor transaction activities and receive alerts on security, finance, operation, and governance events of a dedicated chain. Public detection bots on Forta Network are usually open source, so anyone can subscribe to these bots for alerts. The alerts could be sent by email, Slack notification, Discord notification webhook, Telegram bot push notification, or customized notification webhook. Subscribers can prevent losses by using customized webhooks for automated defense when an alert is triggered. If subscribers want to hide their bot strategy from being read by attackers, who may maliciously trigger their auto-defense measures to jam the project, they can build a private network to host the bots. Private networks are independent of Forta mainet and won’t be involved with the allocation of public detection bots.

Detection bot developers: Any developers can program detection bots on Forta Network and stake a certain amount of $FORT to publish them. Since basic blockchains don’t have many statuses for detection, the development of early public basic bots was incentivized by Forta Foundation’s rewards. As basic bot templates of the network became more complete, later published bots mostly came with a specific detection requirement from a protocol, DAO, or organization. To prevent malicious usage like creating bots to send spam emails or abusing node resources on the network, developers have to stake at least 100 $FORT when launching a detection bot.

Scan node providers: They provide scan nodes that run detection bot scripts to scan all the data of each block. To ensure the stability of nodes in the network and the proper functioning of detection bots, node providers now need to stake at least 500 $FORT for each node. However, since the node supply in the network is way over the demand, Forta Foundation has passed a proposal to increase the stake of each node to at least 2,500 $FORT from September 30th, 2022. Also, to improve the utilization of the network, the foundation proposed to include the number of detection bots running in each node as a metric for node reward allocation.

Upon its launch in September 2021, the Forta community deployed over 650 detection bots and 2,000 scan nodes on the network to scan Dapps on 7 Layer1 and Layer2 blockchains 24/7. As of August 2022, the network has seen 1,200+ detection bots and 9,000+ scan nodes — this is quite an amazing growth.

2.5 Operating Mechanisms and Tokenomics

We will elaborate on the complete workflow and tokenomics of Forta from the perspective of a detection bot:

1. Before a detection bot is published, the Forta network would have a series of preexisting scan nodes, which will run the published bots. Creating a scan node needs a stake of at least 500 $FORT (the stake threshold will be increased to 2,500 $FORT after September 30, 2022).
2. Bot developers will stake 100 $FORT to publish a new detection bot, which will be packed as a docker mirror and sent to one or more good nodes in the network. The quality of a node is measured by its SLA score. Normally, a node with a score higher than 0.9 can be considered a good node. SLA is a minimum between the Resource Score and a weighted average of the Data Quality Score and the Uptime Score.
3. The detection bot will check the data on each block of the chain registered by a scan node. When a strategy of the bot matches the data on the block, it will send an alert to a Forta Network server via Graphql.
4. After receiving the alert, the Forta network server will store it in IPFS, then send out notifications to subscribers via their preset channels (email, Telegram bot, webhook, etc.).
5. Forta Network will issue 400,000 $FORT per week to reward qualified scan nodes. This is also the main source of production of the token.
6. Besides scan nodes and detection bots staking, the $FORT tokens can be used as votes in the project governance to decide its future path.

Here is the current distribution of $FORT tokens:

Community allocation: community allocation is held by the Forta Foundation and includes the rewards in Fortification Phase, airdrops, and future rewards. In principle, tokens from community allocation are not subjected to any lock-ups or transfer restrictions. But in order to ensure alignment with the long-term best interests of the community, some recipients of community allocation must agree on certain restrictions. For example, of the ~2.2% allocated token, ~1.2% is subject to restrictions ranging from 2 to 4 years. For the sake of fairness, community allocation will not have any intersection with early contributors. In other words, early contributors cannot participate in community allocation.

Early contributors: Early contributors include backers, initial core contributors, and OpenZeppelin. Backers refer to the community members that provided early support in funding, network, nodes, etc. Initial core contributors are the earliest Forta Network developers from OpenZeppelin. 20% of the total amount has been allocated to these individuals. As the incubator of Forta Network, OpenZeppelin has gained 10% of the token supply. All of the early contributors are subjected to 4-year linear vesting periods with a 1-year cliff starting from September 1st, 2021. All of these tokens will be fully unlocked till September 1st, 2025.

3. Project Development

3.1 Timeline

3.2 Current Status

3.2.1 Network Overview

As of September 9th, 2022, Forta Network had 9,949 complete nodes and 1,243 bots while monitoring 7 blockchains including Ethereum, Polygon, and BSC.

3.2.3 Usage

Incentivized by the Forta Foundation, Forta Network already has a fleet of established and published detection bots, which can be subscribed to by users directly. And Forta Network has been adopted by a large number of projects and Dapps including dYdX, Lido, Maker DAO, Polygon, Gnosis, and Balancer. Users can subscribe to the monitoring of the following projects (Source: forta.org):

Decentralized Exchanges: Uniswap, Curve, Dodo, dYdX, PancakeSwap, Balancer, Perpetual Finance, ApeSwap

Financing: AAVE, Alpaca Finance, Benqi Finance, Compound, Maker DAO, Umee

Asset management: Lido, Polygon, pSTAKE, Stader labs, Yearn

Others: Ethereum merge, Poly Network

4. Competitions

4.1 Industry Overview

4.1.1 What is a monitoring system?

A monitoring system usually refers to a computer-controlled system with monitoring programs and data-collecting capacity. It is mostly applied in industrial programs, infrastructure, or appliances. In the context of software engineering, centralized monitoring systems are often used for program monitoring and error alerts. Standardized monitoring systems like Prometheus are also widely adopted in the internet industry. Even some cutting-edge Web3 projects still use such standardized systems for node monitoring.

4.1.2 What makes it different for Web3 monitoring?

The biggest difference between Web3 and Web2 monitoring is that Web3 monitoring has a higher demand for real-time coverage. The root cause behind this is the unalterability of blockchain data. Even if a vulnerability in a Web2 service is exploited, irreversible asset losses are unlikely to happen since its database and service logic code is hosted on servers owned by the team — they can fix the hacked data after the exploitation to prevent asset losses. Nevertheless, Web3 applications are usually built on decentralized networks, hence it would be very difficult for the network nodes to reach a consensus to perform data rollback. A data rollback like the 2016 DAO Hack is virtually impossible to happen again. This means asset losses on decentralized networks will be permanent. Therefore, Web3 apps have a much higher demand for in-time monitoring than Web2 apps.

4.1.3 How does monitoring prevent fund losses?

In general, a monitoring system will trigger designated behaviors when it detects events that match certain features. Normally the designated behavior would be sending email notifications, but such behaviors can be customized. When an external monitoring system is applied, users can set up webhooks as the triggered behavior. When a specified event is detected, the system can use a webhook to trigger a preset defense measure. Here is a simple example of how monitoring can help prevent asset losses:

Let’s assume that a Web3 project has applied a monitoring system on its contract owner address — the system will send out alerts when it detects a transaction to alter the contract owner address in the public memory pool. Now a project insider steals the authority of the current owner’s address and attempts to alter it to another address he owns via a transaction. The monitoring system manages to detect this transaction in the public memory pool, and the transaction is not confirmed in the block yet. Here the system will trigger a designated webhook behavior, which sends another address-changing transaction from the owner’s address with higher gas. In this way, the attacker’s transaction will fail and the attempted attack is preempted.

The example above is just a broad elaboration of how monitoring systems work and take defensive measures. While real-life situations could be much more complex than this example, this is still the basic framework of how Web3 monitoring works.

4.1.4 Categories of Monitoring Systems

There are two main models of Web3 monitoring systems: centralized and decentralized.

Centralized monitoring systems are advantageous in terms of lower maintenance costs and more flexible management. But they need a lot of in-house manpower to ensure the coverage of monitoring. In practice, the deployment of monitoring can often be delayed or under coverage.

Monitoring systems built with the decentralized model can incentivize detection bot developers on the network level. And in turn, more developers will be drawn to build an ecosystem together, and thus an in-time coverage of monitoring requirements is achieved. But a drawback of this model is that it’s difficult to formulate a proper incentivization scheme on the network level.

4.2 Competitive Analysis

Several core metrics can be applied to compare monitoring systems horizontally:

Completeness: whether the monitoring categories are complete.

Configurability: the configurability of monitoring thresholds (particularly for existing monitoring categories).

Extensibility: whether it can set up monitoring on a specific contract or feature; whether it can add monitoring of the same category easily.

Timeliness: the timeliness to cover the latest mechanisms.

Usability: the usability of the monitoring system.

4.2.1 Comparison of Famous On-Chain Monitoring Products

Here are several widely-used blockchain monitoring products for comparison: Forta, Epns, Hal, and Tenderly.

We can clearly see the specialties of the products from the graph above.

Forta: Forta stands out in its completeness of monitoring features. Even users with no coding skills can easily set up monitoring with existing templates. Thanks to the incentivization scheme of a decentralized network, it can ensure in-time monitoring development for different types of on-chain behaviors. The decentralized model can also guarantee a certain extent of usability. Its most apparent weakness is the configurability of the detection bots. For example, the specific thresholds for “large amount” or “abnormality” are defined by the bot developers. There isn’t much room for subscribers to customize. Though being a decentralized network, Forta still relies on centralized servers for some features — this may be a hidden trap for its future usability.

Epns: Epns is more oriented to personal wallet monitoring. The advantage of it is when a user subscribes to alerts of a certain Dapp, it can check the watchlist of the user’s wallet and send related alerts. For example, if a user subscribes to Snapshot, Epns will notify new proposals according to the watchlist of the wallet, saving the cost of individual configuration. The main drawback of Epns is its lack of monitoring coverage and its feature updates are lagging behind.

Hal: One of the strengths of Hal is that its DeFi and NFT monitoring features are basically developed. It also has existing monitoring for metrics like liquidity, loan/deposit interests, token prices, large transaction volumes, and collateral rates of on-chain loans. Users are able to configure the above metrics too — this is a big plus compared to Forta Network, on which subscribers cannot edit the specific thresholds. A disadvantage of Hal is it relies on its own developer for monitoring development, hence its timeliness is quite limited.

Tenderly: The most outstanding feature of Tenderly is that users can set up any methods and conditions for contract monitoring. Thus, subscribers can configure highly customized detection bots as they wish. But this could also be a drawback in that subscribers need to have a deep understanding of the target contract. So it’s not suitable for general users. Also, Tenderly lacks features other than contract monitoring, e.g. flashbot detection. Its extensibility is only limited to contract monitoring.

In terms of the product, Forta Network may be weak in configurability, and the limited thresholds of its detection bots may not be good for project owners to build customized monitoring. However, due to its decentralized network incentives, we are confident that there will be some developers that are willing to build customized monitoring for the subscribers. Likewise, with the development of Forta Network, user configuration for detection bots will be developed for sure.

4.3 Conclusion

Web3 security has been a heated topic for years. Users are paying more attention to the security of their crypto assets in terms of contract auditing, code open-sourcing, etc. However, the Web3 security industry is still in its early stage. Since Forta has been adopted by famous projects like dYdX and Lido, Web3 security defense will play a crucial role in the future of blockchain compliance. While many Web3 projects have not adopted any monitoring to guarantee their contract security, the growth potential of the Web3 security market is enormous. From the launch of Forta in 2021, we can tell OpenZeppelin is one of the early players that targeted this blue ocean. Just as how it led the EVM contract development standard four years ago, we are confident that OpenZepplin will be the leader in future Web3 security standards.

5. Risks

1）Detection bot development didn’t receive enough incentives from the decentralized network

So far the Forta Network itself has not started to provide incentives for detection bot development. The main source of incentives now is the bot development contest organized by the Forta Foundation and donations from Gitcoin. From this perspective, the Forta Network has not fully utilized the strength of being a decentralized network. But the community had some discussions on incentivizing detection bot development in recent months, and the proposal also has drawn the attention of Forta developers. We believe they will introduce detailed incentivization schemes for bot development in the near future.

2）The industry lacks recognition of the importance of security

Unlike DeFi, public blockchains, and Layer 2, the sectors that define the ceiling of Web3 user experience, security is more about building up the floor of Web3. When the whole industry is in a craze, everyone tends to care more about the ceiling, not the floor. The importance of security may still need a long time to be fully realized.

Tight antagonism in the community

In the FP-3 voting closed on September 17th, about 51.03% of $FORT voted against the proposal, which was rejected as a result. Such a tight voting result is rare in a big Web3 community — most voting events would end with over 70% of major votes. Though a tight voting result can reflect the engagement of the community, this also reveals the conflict of interest between two parties in the community. This could be a blocker to the progress and development of the project.

References

• Forta Network official site
• Official documents: https://docs.forta.network/en/latest/
• Network status statistics: https://explorer.forta.network/network
• The team’s GitHub page: https://github.com/forta-network
• History timeline: https://twitter.com/FortaNetwork/status/1567591457531527170?s=20&t=LbAJO2Tv7TWOqtBibinhKQ
• Forta Governance Council: https://docs.forta.network/en/latest/governance/
• Forta: https://blockchain.capital/forta/
• Fundraising info: https://a16z.com/2021/09/30/investing-in-forta/
• Forta network statistics: https://dune.com/Sector920/forta
• Forta community proposals: https://snapshot.org/#/forta.eth

About SACTE

A unique and irreplaceable institution dedicated to the emerging frontier of crypto

Website | Twitter | Medium | Mirror