Potential Fees on the Forta Network

[Forta-Foundation]

The Forta Council is requesting feedback from the community regarding the implementation of fees in the permissionless Forta Network. On a number of occasions, the community has brought up the necessity of implementing a more comprehensive incentive model (for example, here and here) to support the ongoing activity in the protocol and to ensure its security and stability in the long term.

In light of these discussions, this initial framework around potential fees in the Forta Network was developed and is now being shared with the community with the hope of kicking-off further discussions about long-term balanced economic incentives for participants in the protocol. This framework (or a different one suggested by the community) can serve as a starting point to think about how tokenomics in the Forta Network could evolve to compensate users for their activities on the network. In this regard, feedback on this initial framework and additional comments/ideas from the community will be gathered and utilized to draft a Forta proposal under the governance process.

First of all, let’s review the protocol’s participants:

• Bot developers/owners: Users that create and maintain the detection bots, which run on scanner nodes and emit alerts.
• Node runners: Users that create, operate and maintain the scanner nodes.
• Subscribers: Users that consume the alerts generated by the detection bots.
• Delegators: Users that delegate their FORT tokens to scan node pools, to increase the economic security of the network.
• Eventually, more roles could be added via the Forta community governance process.

Currently, node runners are compensated weekly for their work in the network, which comes from the finite supply of the community allocation of FORT tokens. Other constituents, notably bot developers, do not currently receive on-going compensation (although many have received grants and contest prizes). The implementation of holistic tokenomics embedded in the network could provide direct compensation to both node runners and bot developers.

Any addition of fees to the network should be done gradually. Also, until an implementation of fees proves to be sufficient to secure the economic sustainability of the Forta Network, the Forta Foundation should continue to support the development of the network through:

• The distribution of FORT rewards to scanner nodes from the community treasury (node runners and delegators).
• Supporting detection bot developers, through initiatives such as threat detection incentive programs, grants and contests.

This post has been organized into three sections (please use these sections to organize discussion in the comments below):

1. Introduction of Fees
2. Pricing and Fee Payments
3. Fee Distribution

1. Introduction of Fees

Subject to community feedback, the Forta Network could activate fee payments using the Forta smart contracts, allowing fees to be deposited and withdrawn, and automatically distributed to network contributors as payments. Initially the permissionless network could support two types of fees:

• Bot execution fees
• Bot subscription fees

Fees could be controlled by network governance. Fees could be different for each supported network (chain ID). Each type of fee could also include tiers, so for example bot execution fees might be higher for bots that consume more node resources (and fees could be waived for some community bots if decided by network governance), and bot subscription fees might be higher for users that require more or additional subscription features (and subscription fees could be zero for some bots and individually adjusted for other bots based on community input and network governance).

In the future, other types of fees could be added through network governance such as:

• Private node fees
• API real-time alert data access fees
• Historical data access fees

2. Pricing and Fee Payments

Feedback from the community is requested regarding the pricing and payment model. For example, fees could be denominated or payable in FORT or USD. In case the community decides that fees should be denominated in USD, price control could be enacted through the use of governance-approved pricing oracles. Users could be permitted to deposit and withdraw fee payments through dApps (like the Forta App). Price changes could be subject to a timelock.

3. Fee Distribution

Fees could be automatically distributed on-chain by the smart contracts on a periodic basis, with the distributions specified by parameters in the smart contracts controlled by network governance. Initially for example:

• Bot execution fees could be shared among node runners and their staking delegates on a given network (chain ID)
• Bot subscription fees could go to the bot developers/owners
• A percentage of some or all fees could go to a community fund designated for rewards, grants, and retroactive funding for other bot development or other network improvements, with those funds controlled by network governance

[eozdemirok]

Hello, I am a node runner since May 2022. I am also a bot subscriber. I am writing with 2 identities while writing here. A return was a must for the system to be sustainable. It will settle and be adopted over time.

Node runners:

• There are costs for node runners. This includes server, electricity, maintenance (time) factors. If the earnings are not above these, it may cause many nodes to be shut down. I know you know this, but I want to tie it somewhere. The base payment should be determined. I will talk about this later on.

• I think the actual existence of the node depends on the assignment of bots rather than the chain. It seems that there are still too many nodes in the last upgrade. This is because the rewards of the runners who close the node will be slightly reduced. I have 12 nodes that belong to me and I will not close them. This is good for me, bad for the system.12 There are nodes and only 4 of them have bots. I recommend gradually increasing the minimum stake to maintain the balance. First, 5000 forts can be made. Then, if the system is monitored and not enough drops, 7500 forts can be made.

• The time of the payments for the node runners has always been different. It came at different times of the days such as Monday, Tuesday, and Wednesday. Why couldn’t a system that builds the whole system on its bots pay for the prize distribution at a certain time and day? In this case, I think it will be fixed in the new system.

• No outsiders for the delegate.These are tokens already added by previous owners. different incentive should be added for this. example below
  /1,000 fort delegates - Tier 3 bot subscription free
  /3,000 fort delegates – Tier 2 bot subscription free
  /6,000 fort delegates – Tier 1 bot subscription free
  /10,000 forts or more delegates – the most important and proven bot subscription free

Bot developers/owners :

• Incentive for bot owners and developers is definitely important. This will help the bot evolve and new creators come in.

• A certain share of the pool from the revenues that can be obtained will be allocated here. The minimum payment offer I said for the node runners above should be made among the bot developers. When bad conditions occur, no one has to quit their job and continuity is ensured. Although it seems negative for the treasury at first, the burden of the treasury will decrease in the future.

Subscriptions:

• It is an application that I feel absolutely safe as a subscriber to -bot. However, the fact that it is free will not ensure system continuity. Certain conditions must be charged for this.

• The bot fee should increase according to its importance. Bot fees should not be charged on an ongoing basis. If it is taken, it will make people uncomfortable. With the subscription fees of 3 months / 6 months / 1 year, as in the campaign, we can show people in a way that makes it easy to use and pay.

• For individual subscribers, it should not exceed $20/30 per year. Above these prices will drive people away. For corporate subscribers, it will be better to work monthly. It will have constant variables and the numbers it protects will constantly change.

• Reward-based work can be done for great protections with corporate subscribers. 1% reward agreement can be made by the institution for the protected and recovered asset. This reward can be shared by the node runner, the bot owner and the treasury.

• We should present the bots that make more detection to people in a ranking and they should see the work they have achieved. They can subscribe to the bot they like from here

• I would like to offer a suggestion for bot developers. We should think like attackers. I get a message when there is a movement in my wallet, but I can’t take action immediately. Let’s think about it. I have 30 different tokens in my wallet. While I want to recover 1 of them, 29 can be stolen by the attacker.
  The system I imagine: While subscribing to the bot, let me give you a 2nd wallet address that belongs to me. And when it is certain that my wallet will be attacked, the contracts previously given by the bot should be activated and the transfers to my 2nd Wallet should start. Even if there is no attack here, my only loss is the fee fee. I think it will revolutionize the field.

• The rewards that bot owners and developers will receive should be directly proportional to the network they are in. It is not fair that the etherium bot owner and the phantom bot owner receive the same reward.

• We should see the number of sign-ups by starting the subscription fees with a half discount in the first place. We reduce the discounts when there is enough demand. Until this system is established, the treasury should continue to make payments in the next year. As the earnings increase, the amount to be paid from the treasury decreases. continuity is ensured.

[body]

I completely agree with eozdemirok. you need to redo the model, it shouldn’t be the same as it is now, at the moment you are just killing the project with your myopia

[shi_jing]

Building a good ecosystem is the key factor for the success of a project. A good ecosystem can self-cycle and self-balance. The various roles in the system can complete their own work without much external interference.

I think users can be divided into two major categories, producers and consumers.

1. Producers benefit (node runners, bot owners, delegators)
2. Consumers pay (subscribers)

Under this basic principle, design a reasonable rate of charge and payment, preferably this rate is not fixed and can be adjusted in real time according to the network status, so that the whole network can be self-adaptive. This means that the income of producers is not a fixed value, but is determined by the expenditure of consumers.

[xaler]

I’m writing here as a bot developer and subscriber

Regarding: Bot execution fees

A lot of bots executes to just discard the transaction without returning any finding. Maybe it might make sense basing the fess on findings more than on executions. Like that findings consume the stake of the bot or similar.

Regarding: Bot subscription fees

This might make sense too but I see a workaround of using the API instead of subscribing to alerts. There would be some latency in there but someone might still get the alerts through the API instead of subscriptions. They will just need to wait for the API to index the data.

Moreover, my main use case is to chain bots together by subscriptions (ie a bot subscribed to other bot’s alert). I would make a special case for subscriptions between bots since it might kill an useful use case of composability and modularity of bot systems.

[sirius]

I totally agree with eozdemirok. A new system must be implemented.

[chadCode5566]

As a node runner since the start of Forta Network, I always consider it better to distribute rewards based on number of bots per node. At least, nodes that are assigned with more bots should be compensated with some premiums. Nodes assigned with bots consumed the compute resources & traffic, but get the same rewards as nodes without bots? Just seems weird to me. Some suggestions:

• Every node has a base reward, this is for setting up nodes awaiting for bots. Overall nodes without bot still secure the network as backup runners.

• Aside from base rewards, a bot reward should be given to nodes that run bots.

• We can regularly rotate bots between nodes to make rewards more even. A side benefit: if a node does not meet SLA standard when assigned with bots, this potentially means the node is running on some low quality hardware or limited network bandwidth, which is not good for the network.

[Idan_Levin]

Thanks for this community update.

I think that the network should separate the discussion between the supply side (i.e. bot owners/node runners) and the demand side (i.e. subscribers).

It might be the case that the supply-side want to get paid X but the demand side is only willing to pay Y so they never meet.

I believe that like in any startup you start with the customer, so the big question is - are subscribers willing to pay today, how much, and for what? (Steve Jobs - Start with the Customer Experience - YouTube)

I think we should split the discussion completely and break down only the demand side analytically. The demand side can also be comprised of end customers or other bots like @xaler specified.

According to my acquaintance with the monitoring market today (from its centralized side), the market is still quite small, and it might be the case that the total paying user base is actually not too big, and that network needs to currently pay and subsidize the demand side. If the goal of Forta is to be THE monitoring network in a few years, then like any other network, it might be wise to try and stay away from monetization as much as it can so more potential users of the network could tap in without paying anything.

I also think that pricing should be derived from the end goal of the network, and areas with strong strategic importance (like @xaler stated bot2bot integrations) should be as frictionless as possible with regard to current economics.

Anyways I would love to help with any financial modeling.

[yale.vinson]

I agree with @Idan_Levin. We must establish the needs of the customers to ensure we are building the right tools for the right price, etc. Until we do that, we are wandering in the wilderness without a map. We could get where we ultimately want to go, but with considerably more effort and more by luck than anything else. That said, I think this is a topic for another symbiotic thread to this one.

On the topic of incentives and fees I think this post is a good start, but if we are going to get people to commit to developing Bots, things need to be more well defined. To that end, here are a few thoughts on the areas defined above:

Introduction of Fees
Assuming I am interpreting this section correctly, there are fees paid to the Builders/Owners based on the quality and utility of their bots, and “fees paid by” Customers that subscribe to the Bots and the Feeds to which they belong. Since we intend these Bots to be appealing to the entire community (protocols, networks, consumers, institutional investors, etc.), Customers should have the ability to subscribe to individual monitors or a Feed that is an aggregated collection of Bots based on their needs. Consequently, each Bot could have multiple potential revenue streams depending on their appeal and utility, with 100% of the available revenue going to the Developer/Owner for individual Bot subscriptions.

Since there can be no carrot without a stick, Developer/Owners must stake enough in their Bot to cover cases where they consistently perform poorly. I know that there is accommodation for this already, but we will need to revisit the stake so that it is commensurate with the reward level to avoid “rug pull-like” behavior.

I also agree that the fees should vary based on the network, but that gets quickly convoluted and murky. Consequently we should make the scheme as simple as possible in a pilot, and then extrapolate to other chains once we have a model that works. I would also recommend keeping the fee tiers simple at first to avoid creating confusion from the start of the program; we can always add categories as the population matures.

Pricing and Fee Payments
I am not too concerned with the currency used for the payments, as once set they will be normalized within the network (in essence, it is what it is). FORT would be simpler to manage, and lead to fewer disputes about someone getting a bad rate due to timing, etc.

I do want to address the fees associated with the Bot Lifecycle, as I think it is important to consider all phases of a Bot. As considerable effort will go into creating Bots that are valuable to the community, I think there should be accommodation for development subsidies. This can range from partial subsidy from the Network (or by extension the Community) to 100% paid by a Customer of the Bot Developer. In all cases, the economics of this phase of the Bot are not accounted for in the operational fee structure. One potential exception would be for network subsidized Bots that are successful to pay a portion of the profit from their fees back to a Bot Subsidy Fund (a sort of “pay it forward” mechanism), but I think this is something that should be done once the Developer community is well established.

One other type of fee to consider is an extra reward for Bots that either alert a Customer to an impending catastrophe, or recover funds lost due to an event. In this case, we could set a percentage of funds saved/recovered as a network standard, or make that percentage a part of the Bot Subscription Agreement. This would allow more upside for the Developer/Owners that should attract better Bots and more serious contributors.

Fee Distribution
With regard to the Bot Execution Fees and Bot Subscription Fees, I think normalizing the Execution Fees should be fairly easy to do in most cases, based on the number of instances deployed, resource required to execute, etc. The question I have is are these fees paid by the Bot Owners or do they come from the subscriptions? I think either way they can be baked into the subscription fees, and eventually we could get into a scenario where Owners put some skin in the game beyond their Bot Stake, but asking for that in a nascent ecosystem will be a considerable barrier to entry for the Developer/Owner community.

Bot Subscription Fees should go to the Developer/Owners and called out clearly in a Bot Subscription Agreement as to how those funds are managed, paid, disputed, etc. We can draft a boilerplate for each tier and stick to them to get things started, and see if there is a need to allow some flexibility in them as the market evolves. For example, there should be a set of Agreement templates for the tiers for Individual Bot Subscriptions, and then standard Agreements for the Bot Feeds that aggregate the Bots. Then Owners can enter into the agreements for the cases that apply to each of their Bots.

I know there are things that I am overlooking, but I may have droned on too long already. Suffice it to say I am interested in continuing this conversation and evolving these fees to a practical conclusion which benefits the Forta community.