Forta Proposal 5 (FP-5): Fee Framework


Based on the constructive community feedback on the high-level fee framework discussion in the forum, the Governance Council commissioned the development of this more concrete proposal to implement initial peer-to-peer fee architecture in the Forta Network, to now be reviewed by the community for final input before being presented as a formal proposal for FORT token holder voting under the FPP process (as things stand, this would be FP-5).

There is general consensus in the community that there needs to be long-term balanced economic incentives for participants in the Forta Network in order for the protocol to be sustainable over the long-term. The fee framework below proposes the first development and implementation of an initial technical architecture that could enable Forta users to compensate network participants on-chain for their valuable work (i.e. deploying helpful bots, properly running nodes, delegating stake for security).

This fee framework proposal has prior feedback baked-in, but please do not hesitate to share any additional feedback or comments that can be incorporated prior to this FP-5 proposal moving to the formal FPP voting process on the Forta Snapshot.

(FP-5): Adding Data Fees to the Forta Network

Forta Data Fees

  • Forta Data fees would be implemented so that subscribers must pay for access to alerts, findings, and labels generated by the Forta Network, which would provide rewards to the participants in the network that generate that data.

  • Users could select among different 30-day plans, enforced on-chain using the open-source Unlock smart contracts (see “Technical Architecture” below for more information). Unlock plans can be configured by the user to auto-renew to ensure continuous service.

  • Different types of plans will enable access to different sets of data. Initial plans could include plans for the following data types:

    • General Plan: Paid access to the Forta data generated by typical types of bots in the network (e.g. the majority of bots in the network currently).
    • Special Plans: Paid access to specialized data feeds (each of them purchasable separately at tailored pricing), with data coming from one or more specialized Forta bots.
    • Free Plan: Free access to certain Forta data determined to be public goods by the network.
  • Each Forta bot could only be included in one data plan at a time (see section below for more details).

  • Paid users would receive NFTs and related API keys, which would enable them to access data from the plans they have purchased.

  • Fees would be denominated in FORT and additionally in USDC. Users could then be able to choose in which token they prefer to pay each plan.

  • Users could cancel at any time, keeping access until the last day purchased.

  • Insufficient funds (or not enough approved funds) in a user’s wallet at the time of renewal would result in the lapse of the plan for the user (i.e. their NFT representing their active plan would expire and related API keys would lapse).

  • If a detection bot itself reads Forta data, the bot owner would need to pay respective data fees for the data they rely on (from the corresponding plan).

  • The Forta Foundation could fund the development of this fee architecture, including UI updates to support fee payments in the Forta App, however users would always be able to pay fees directly to the smart contracts if desired.

Assignment of Bots to Data Plans

  • By default, newly created detection bots will be assigned to the General Plan.
  • Governance will have the responsibility of setting the price for the General Plan at a later date.
  • Any bot owner will be able submit a request to Governance to create a new special plan to include the data from their bot (and remove it from the General Plan). This request could include things like the desired pricing for the new special plan, which could also be free.

Bot Developer Rewards

  • Data fees would be collected into the respective Unlock smart contract related to each plan.
  • Data fees for each plan would then be distributed as rewards to the bot developers who create and maintain the detection bots in that plan.
  • Rewards could be distributed on a weekly basis to align with node rewards, by distributing 23.3% (7/30) of the accumulated fees at the end of each epoch.
  • Distribution of rewards to bot developers among each plan could be based on the number of users that are subscribing to each bot. Free bots would not be rewardable.

Technical Architecture

In order to utilize established smart contracts, it is proposed that the Forta Network implement the fee architecture outlined above using the Unlock Protocol smart contracts. Unlock offers a number of benefits including:

  • The Unlock smart contracts are open-source, including the Lock Factory contract, which would be used for creating new Locks to enforce fees on-chain in the Forta Network. Locks are time-based, auto-renewable, subscription-enabling smart contracts (each plan in each token would have a respective Lock).
  • Unlock offers additional functionality for users (e.g. helpful payment mechanisms), which is currently free.
  • Unlock is also in use by other established web3 projects such as TheGraph.
  • Implementing the initial fee structure in the Forta Network using Unlock would not present significant reliance on Unlock (i.e. switching to an alternative technical solution is feasible).

The implementation of the fee architecture outlined above could include modifications to the Forta App to support the payment and management of fees, however users would always be able to pay fees directly to the smart contracts if desired.

Future Fees

The introduction of Forta Data Fees is being proposed as an incremental addition to the Forta Network and would not restrict the Forta community from identifying and adding other types of fees in the future. Other fees may be added to the Forta Network through further proposals and community approval. For example, there has been discussion about bot execution fees that could be paid by detection bot owners to directly reward node operators and their delegators for running bots on the network. As always, members of the Forta community are encouraged to explore how the Forta Network can evolve and explore how other types of fees might promote the long-term health of the network. In particular, the Forta Foundation will continue to work with the community to explore how bot execution fees could work.


good idea! forta will hot

at the moment, any fee will only repel potential users, if you want to raise the cost of your project, then you need to introduce not payment with tokens, usdc, but pastor a model in which tokens will be blocked, which in turn will reduce the supply in the market
as for the payment to bot developers, the model should be built in such a way that if a fort protected a protocol from hacking, then a certain amount should be paid by this protocol, part of which will go as a reward to the bot developer
what you are proposing now is another road to nowhere

1 Like

Hi @body , thanks for your feedback. I sometimes have a difficult time understanding the intentions of your comments, considering the offensive nature of them. The Forta community is a very open and respectful one, and despite differences in opinions that there can be (that is what is enriching in the end), the goal is to always have constructive discussions in an educated and positive way that can lead to the best outcome for the Network.

As the proposal describes, the key element is to enable balanced economic incentives for participants and sustainably incentivize contributions to the network. In this case, if there is significant value that a user can get from the data that a bot is producing and is willing to pay for it, why do you think it is wrong that the developer that spent hours working on it gets that payment?

1 Like

I support the fees for alerts proposal with some additional comments/suggestions.
As crypto has yet to reach the masses , the most users who will be willing to pay are those who are having very large funds to protect. So we have to be ready to fine-tune the fees/plans as per market demands. Taking every little change though governance mechanism can be bit time consuming so foundation should be doing tweakings as required in Pricing.

I don’t know how feasible it would be to tie the bot fees to the amount of funds it’s protecting, but that could be looked into.I guess there could be special bots under proposed special plans with higher prices who have high ratings in protecting funds/raising alerts.

Also I think it would be a good idea to offer an additional option to allow users to lock (Delegate) a certain amount of FORT for using the bots if he doesn’t want to pay fees for using the bots. The rewards for Delegated FORT could go to the Bot Developers. This way the user doesn’t have to spend any money on services but will have to Buy & Delegate FORTA for using the Bot Network. This will increase the security of the network and also bring in new users who will have to buy FORT.
There is a L1 chain which does not charge a fee for transactions but the user has to stake some coins for a few days if he doesn’t want to pay the fees.

Bot Execution fees is required to be implemented soon, if possible with this proposal only as Bots consume Node resources and right now there is no provision to compensate Nodes who run more bots.


Hello. I didn’t want to offend anyone in any way (maybe this is all because of the translator, since English is not my native language), I just wanted to say that there should be a payment, of course, but it should be implemented in the token blocking model, and not in payment fiat
which in turn will increase the demand for the use of the token
also, the reward to developers should be implemented in such a way that the bot created by this developer protects some protocol and this protocol pays a certain amount, part of which goes as a reward to the bot developer

Thanks for clarifying! It was probably a translations issue and I think we agree on most of the things.

Regarding the payment method, this proposal is in line with what you say about payments being made in tokens and not in fiat, and includes FORT and USDC.

Then, regarding a model that locks tokens (stake tokens to get access to the data) versus a model in which fees are paid in tokens (pay tokens to access data), to allow for what you mention in your last item (ie. the bot developer earns the fees that the protocol pays for using the bot that the dev created to protect the protocol), a payment model is needed (and that is the one which the proposal includes), since under a lock model those tokens can’t be sent to the developer, but need to be kept and then returned to the user (protocol in your example).

I support this future proposal and agree with @anurg.

I believe there should be a high degree of flexibility in experimenting with fees and various plans. Since obtaining governance approval for each change could be cumbersome, the Forta Foundation should be pre-approved to have sufficient leeway to experiment without needing to consult the community each time.

In my opinion, the most suitable economic model for the network is constant fees. As for locking FORT for data streams, I’m less enthusiastic about this approach, as it necessitates capital expenditure from users of the network (pre-paying with a large capital amount), as opposed to fees which are OPEX and more efficient. It also creates an excessively strong direct correlation between the operational usage in the network and the FORT token price, which I consider unhealthy. Additionally, this model requires users to perform due diligence to secure the network, while they will likely just want to use the data feed. To me, this seems less reasonable.

1 Like

I fully agree with what you have suggested that for some, it may be a capital expenditure to invest in the network while they just want to use the services of the network. Its like you buy Mcdonalds share to enjoy burger :smile: It should be an option for the FORTA fans who have researched and sold to FORTA project potential and holding coins. The other way of analysing could be to think of all the customers of the network which includes network participant also (Node Runners, Delegators, Protocols, VC Funds, Big Invetsors) and have multiple payment terms which appeals to all. Thanks!


Thank you everyone for your thoughtful feedback over the past months!

The snapshot voting on the Forta Fees’ Proposal starts Today, May 9th, at 2pm ET and will end same time on May 12th. All FORT tokenholders are encouraged to vote!

What’s the reasoning for accepting USDC and also FORT? If FORT is the utility token of the Forta network, why not require payment in FORT?


1 Like

from what I read, you would be able to pay in FORT or in USDC. i think this is probably going to be important for those relying on alerts for security to know exactly how much balance to have to make sure their subscription stays active. those who earn FORT or buy FORT could use that method, and I agree that it is important that at a bare minimum you can always pay in FORT. maybe if there is another reliable stable that could work too

FP-5 voting just concluded with the Forta community approving the measure with a 96% approval.

Fees are coming to the Forta Network! Protocol and UI integration of fees will roll out in the coming months